Camera exposure and gain properties missing after a GStreamer upgrade

You upgraded the GStreamer source plug-in for your machine-vision camera, and gst-inspect-1.0 no longer lists ExposureTime or Gain for a camera that streamed without trouble the day before. The vendor viewer still sets both values, and the pipeline still delivers frames. This guide is for the engineer who owns that pipeline. In ten minutes you can prove the camera is fine, put exposure and gain control back into your application today, and set up the version check that keeps the same regression out of production.

The decision, first

Treat vanished properties as a plug-in regression, not a camera fault. Three facts give it away: the properties disappeared the moment the plug-in version changed; the vendor viewer still sets ExposureTime and Gain on the same camera; and the stream never stopped. A camera-side fault does not track a plug-in release, and firmware is intact whenever the viewer works.

So the plan is fixed: keep the pipeline running, write ExposureTime and Gain through the GenICam API for now, and move to a plug-in release whose gst-inspect-1.0 output lists both properties again. If no fixed release exists yet, pin production machines to the last version that listed the properties and hold there.

Expect a narrow failure. On the same upgraded plug-in, a camera with a different feature tree can keep every property it had. One model losing exactly ExposureTime and Gain while another model keeps them is the signature of this regression, and it clears the hardware.

Why an upgrade can hide camera features

A GenICam source element builds its property list when it connects to the camera. It walks the camera's feature tree — the GenICam XML the camera itself serves — and maps each supported feature onto element properties you can set from gst-launch-1.0 or your pipeline code. ExposureTime and Gain are standard GenICam feature names, so nearly every industrial camera exposes them this way.

Rewrite the introspection code and that walk can fail on a tree it handled the day before. A plug-in that fails politely skips the property instead of refusing to stream, so you lose the two shortcuts and nothing else. The viewer never runs that property builder: it reads the same tree through the SDK, which is why it keeps working while gst-inspect-1.0 comes up short.

Two habits follow. First, read the Plugin Details block that gst-inspect-1.0 prints for the element — version and loaded file — before you compare two runs, so you know which binary answered. Second, send the vendor both outputs, old version and new, with a GST_DEBUG log of one connect attempt; that is the report that got this exact failure reproduced and fixed in the next minor release for one camera family.

Diagnose it in ten minutes

Run the tests in order; the first three decide the case.

1. Confirm the loaded plug-in. gst-inspect-1.0 yoursource prints a Plugin Details block with version and file. If it is not the version you meant to install, fix the installation first — a mixed install mimics every symptom below.
2. List the properties. Pipe the same output through grep -i -e exposure -e gain (findstr on Windows). ExposureTime and Gain absent means the plug-in never created them: introspection regression. Properties present but writes failing is a different case, covered at the end.
3. Prove the camera still owns the features. Open the vendor viewer, set ExposureTime to 400 µs and Gain to 6 dB, and read both back. Accepted and returned means the feature tree is intact; no firmware, driver or camera work is justified.
4. Cross-check a second camera on the same plug-in version. Pick a model from a different generation — area scan cameras on every interface expose the same two features. If the second camera still lists the properties, the regression is confirmed as tree-specific.
5. Write the values from your own code. Open the camera through the SDK's GenICam node map and set ExposureTime and Gain there; setting camera exposure time through a GenICam API in Python shows the write step by step. Success here, with the pipeline property still missing, proves the gap is the property mapping only — safe to bridge and ship.

Fixes, in the order to try

1. Upgrade past the regression. Read the plug-in release notes for an introspection or property-mapping fix; the report pattern in the FAQ above is what got this exact failure fixed within one minor release in the documented case.
2. Pin back while you wait. Reinstall the exact previous version, record it in the build manifest, and hold production machines on it until the fixed release is tested on your camera model. The same version discipline that keeps a robot vision plug-in matched to its program keeps a source plug-in matched to its cameras.
3. Bridge with the GenICam API. If the new plug-in must run today, keep the pipeline for streaming and write ExposureTime and Gain through the node map at startup, before the stream starts. Values set through the SDK hold for the session, so one setting script covers the missing properties. For gain changes mid-run, changing camera gain at runtime without stopping the pipeline shows the same pattern through code instead of pipeline properties.

Whichever route you take, capture the fix as a test, not as a memory: the property snapshot in the next section turns this from a one-off repair into a permanent check.

Set the value right, then prove it landed

The bridge is only as good as the number you write, so work the exposure from the image side:

Worked example: the belt runs at v = 250 mm/s and the camera sees FOV_width = 160 mm across N_px = 1600 pixels. One pixel then covers s_px = 160 mm / 1600 px = 0.10 mm of the part. Holding motion blur under one pixel needs ExposureTime ≤ 0.10 mm ÷ 250 mm/s = 0.0004 s = 400 µs. If the scene is too dark there, add gain: 6 dB gives G_lin = 10^(6/20) = 10^0.3 ≈ 2.0, so counts double.

Then prove the write reached the sensor. Read the node back after writing: 400 and 6, not a stale default. On a static scene at fixed gain, double the exposure from 400 µs to 800 µs — the frame mean should roughly double. Return to 400 µs and raise gain by 6 dB — the mean should roughly double again. Keep the histogram below clipping. Two means that move as predicted tell you the GenICam path is doing the job the missing properties used to do.

Prevent it: snapshot the property list

The entire failure is visible in one text file. Snapshot it at acceptance, then diff it at every upgrade: gst-inspect-1.0 yoursource > camera-model_plugin-version.txt.

Keep one file per camera model per plug-in version with the project. After an upgrade, diff the new output against the stored file; if ExposureTime or Gain disappears from the diff, block the upgrade on that machine and stay pinned. The check is one command per camera and takes seconds, which turns a field failure into a lab catch.

Two habits make the pin solid. Keep a reference camera with a known feature tree on the bench, so a suspected regression always has a control — the discipline in starting a camera test from a known state applies unchanged. And treat the acquisition layer as one versioned set: source plug-in, camera SDK and GenTL producer move together, for the reason GenTL producer version compatibility explains — mismatched layers fail in ways that look like camera faults but are not.

When it looks like this but is not

Same symptom, different layer — each of these has its own fix:

• The property is listed but writes fail or are ignored. That is a writable or feature-mode problem, not a missing property; GenICam attribute not writable: set the feature mode first walks the fix.
• ExposureTime is missing from the node map itself. The SDK cannot see the feature either, so the camera or SDK side is the suspect; GenICam exposure feature discovery for missing attributes covers that path.
• No video after the upgrade. A plug-in that cannot open the camera builds no feature properties at all, so a dead stream and a short property list travel together; start with camera connected but viewer shows no video: GStreamer missing plugins.
• The camera vanished from the SDK's enumeration. An installation or driver-layer problem, not introspection; camera in Device Manager but not in your SDK: the missing plugin sorts it.

Every one of these leaves the viewer's behaviour as the tell: when the viewer still sets ExposureTime and Gain, the camera needs no hardware attention.

Bench and parts for the retest

After the fix lands, re-baseline on hardware you keep for the purpose. The control test from the diagnosis needs a second camera with a different feature tree: the 12 MP USB3 camera LS-CMR-0166 stands in for the affected USB3 Vision model, and the 2.5 MP GigE MV-CU020-90GC exercises a different interface on the same plug-in.

Run the pinned version and the candidate version side by side on one bench machine, so registry, SDK and drivers stay identical across tests. A dedicated host such as the MV-VC2140-128G40-1T carries two USB 3 ports and four built-in light channels on an Intel N-series processor, enough to run camera and lights without borrowing a production PC.

When a new line is on the drawing board, run the same snapshot before you commit: the camera finder filters by interface and shutter, and the vision controllers page narrows hosts by ports and camera capacity. Each shortlisted model earns its own gst-inspect-1.0 snapshot the day it arrives.

Decisions at a glance

If you are standardizing cameras or hosts while the version matrix settles, the camera configurator pairs a camera with lens and light in a few steps, and the contact page reaches the applications team when a stubborn version matrix needs a second pair of eyes.