How to query camera capabilities with GenICam

An application can discover an unfamiliar camera’s configurable features without a hard-coded model table, but discovery must include the camera’s current state. A maximum reported before changing pixel format or exposure may not remain valid afterward. This procedure is for developers building reusable acquisition software. You will learn which feature nodes to inspect, how to record their constraints, and how to verify that an accepted configuration actually produces the required images.

Prepare a capability report, not a model lookup

Use the camera’s supported acquisition library and its documented GenICam feature interface. Start with exclusive configuration access when possible, acquisition stopped, and another application disconnected. Do not assume that identifying a transport interface establishes support for every optional feature.

Keep discovery separate from configuration. The discovery pass should inspect features without executing commands, loading presets, or changing acquisition settings. Otherwise, querying capabilities can unexpectedly alter the system you are trying to characterize.

Record these fields for each feature:

Treat this report as a snapshot, not a permanent specification. If a candidate feature is absent, use the missing-node diagnostic procedure before deciding that the capability is unsupported.

Open the correct feature map and check access

1. Enumerate devices, select the intended device, open it through the supported library, and obtain its remote-device feature map.

A library may expose separate maps for device discovery, transport configuration, stream handling, and camera features. A stream-buffer setting is not a sensor-width setting. Looking in the wrong map can make an existing feature appear absent.

2. Inspect each candidate node’s implementation, availability, access state, and interface type before reading its value.

Use the library’s documented access helpers. Depending on the API, these checks may be separate predicates or interpretations of an access-mode value.

Distinguish the failure cases:

• Absent or not implemented: the requested feature is not exposed through that node.
• Unavailable: the node exists but depends on another setting or operating mode.
• Not readable: its value cannot currently be queried through the normal read interface.
• Not writable: it may be read-only, locked during acquisition, or restricted by the current access session.
• Communication error: the read failed; this does not establish that the feature is unsupported.

Use the node’s interface type rather than guessing from its name. Integer nodes have different constraints from floating-point nodes. Enumeration nodes expose named choices, while command nodes represent actions rather than ordinary values.

If a feature can be read but not changed, follow the camera access-state checks. Do not repeatedly attempt writes as a substitute for checking permissions.

Query dimensions and distinguish their meanings

3. Inspect supported dimension features, including Width, Height, OffsetX, and OffsetY, and query each numeric node’s current constraints.

For Width and Height, record the current value alongside the minimum, maximum, and increment. The maximum returned by the configurable node describes its allowable range in the current state; it is not automatically the sensor’s physical dimension.

Features such as WidthMax, HeightMax, SensorWidth, and SensorHeight may provide additional information when implemented. Read their descriptions and units. Do not treat their names as proof that they all describe the same image geometry.

Several effects can make these values differ:

• A nonzero offset can reduce the remaining space available for the image region.
• Binning or subsampling can change the relationship between sensor coordinates and delivered pixels.
• A selected sensor mode can expose only part of the sensor.
• Pixel format or processing settings can impose additional alignment requirements.

For ordinary integer nodes with a fixed increment, select a value on the reported grid. The following rounds a request downward, provided the request has first been clamped into the valid range:

For a hypothetical width node with minimum 64 pixels, maximum 4096 pixels, and increment 8 pixels, a request for 2051 pixels becomes:

This is a candidate, not a guarantee that every combination of settings is legal. Some interfaces expose additional constraints or supported-value lists. Write through the documented setter and read back the accepted value.

To understand when source-side cropping helps, see camera ROI cropping before host transfer. For changes that alter sampling rather than just image boundaries, compare ROI, binning and subsampling.

Discover frame-rate controls and their dependencies

4. Inspect the acquisition mode, trigger configuration, pixel format, exposure controls, and any implemented frame-rate controls before interpreting a maximum rate.

Common candidate names include AcquisitionFrameRate, AcquisitionFrameRateEnable, ExposureTime, ExposureAuto, TriggerMode, and PixelFormat. These are discovery targets, not a promise that every device exposes them or uses the same feature revision.

A frame-rate control can be absent, disabled, unavailable, read-only, or irrelevant to externally triggered acquisition. A resulting-rate feature, when provided, may describe an internally calculated operating rate rather than the value you requested.

Read units from the node metadata or documented feature definition. Do not assume that an exposure number is milliseconds, or that a floating-point value has a fixed increment. Some floating-point nodes expose increment information; others do not.

For example, an exposure of 20,000 microseconds lasts 0.020 seconds. The exposure-only reciprocal is:

That estimate is not a complete timing model. Readout, overlap behavior, trigger handling, and transport constraints can reduce the achievable rate. Query the current limits after setting exposure rather than substituting this calculation for the camera’s documented timing behavior.

For exposure-specific node handling, use the exposure feature-discovery procedure. If your application already finds the feature but needs to configure it, follow the GenICam exposure-setting workflow.

Build a state-aware discovery loop

5. Implement a typed inspection function, then call it again after configuration changes that can affect other features.

The following is pseudocode, not a portable SDK interface. Implement each operation using the acquisition library’s documented methods:

function inspect_feature(feature_map, name):
    node = lookup_optional(feature_map, name)
    if node is absent:
        return record(name, status="absent")

    report = describe_type_and_access(node)
    if not report.implemented or not report.available:
        return report

    if report.readable:
        report.value = read_typed_value(node)

    if report.type is numeric:
        report.unit = read_unit_if_exposed(node)
        report.constraints = read_supported_constraints(node)

    if report.type is enumeration:
        report.entries = inspect_entry_access_states(node)

    return report

Preserve a distinction between a value that is absent and a value that could not be read. Record exceptions with the feature name and operating state. A disconnected device should produce a communication fault, not a capability report filled with unsupported features.

For enumeration entries, record their access state rather than copying every symbolic name into a selectable list. A listed option may be unavailable under the current configuration. The enumeration symbolic-value checks explain why a plausible string can still be rejected.

Avoid querying every feature on every received image. Build an initial report, refresh it at configuration boundaries, and use documented change notifications where available. If feature inspection interferes with streaming, investigate feature-browser freezes during acquisition.

Apply changes in a controlled sequence

6. Configure one dependency group at a time, re-query affected constraints, and verify every accepted value through readback.

For a basic area scan configuration, a practical sequence is:

• Stop acquisition when the documented interface requires it.
• Select the required acquisition and sensor operating modes.
• Select pixel format and any required sampling settings.
• Re-query ROI ranges and increments.
• Set ROI size and offsets in the documented valid order.
• Set exposure and its automatic-control state.
• Re-query frame-rate access and range before requesting a rate.
• Read back the configuration before starting acquisition.

There is no universal ROI write order. When permitted by the device, reducing offsets to their reported minima can make a larger image region available. Other devices require a different sequence or a dedicated transaction. Follow the documented dependency rules rather than assuming that offsets always accept zero.

For example, changing from a single-component format to a three-component format increases uncompressed image data when each component uses the same storage depth. That can affect transport demand even if image dimensions remain unchanged. The pixel-format and frame-rate discussion covers that distinction.

Once configuration works, separately verify saved settings and startup readback. A successful runtime write does not establish what the next connection or power cycle will restore.

Verify delivered images, not just accepted settings

7. Start acquisition and measure complete-frame delivery over a defined interval using a monotonic host clock.

For example, receiving 300 complete images over 10 seconds gives an observed delivery rate of 300 / 10 = 30 frames/s. Exclude startup transients deliberately, document that choice, and repeat under the intended processing load.

Record incomplete frames, timeouts, frame identifiers, and camera timestamps where the interface provides them. Distinguish receiving a frame from processing or displaying it. A display loop running slowly does not necessarily mean acquisition is slow.

Under external triggering, compare accepted images with the known trigger sequence. The internal frame-rate setting may not determine the trigger frequency, and closely spaced triggers may be rejected or handled according to the camera’s documented behavior.

Before accepting the capability report, check:

• Device identity and the feature description version were recorded when available.
• Each required feature was inspected in the intended operating state.
• Numeric units, bounds, and supported increments were captured.
• Enumeration choices were checked for current availability.
• Accepted writes were confirmed by readback.
• Complete-frame delivery met the application requirement.

Choose hardware from requirements, then confirm discovery

Use runtime discovery to adapt software, not to replace selection requirements. Define the needed image dimensions, shutter behavior, interface, trigger behavior, and sustained delivery rate before comparing area scan cameras in the camera finder.

The LS-CMR-0053 is a GigE area scan camera that can serve as a catalog starting point.

The LS-CMR-0166 provides a USB3 area scan alternative for evaluation.

These examples do not establish support for any optional feature discussed above. Confirm required node availability, access behavior, and timing through manufacturer documentation and an evaluation with your acquisition library.

Runtime discovery is insufficient when the application needs behavior the feature interface does not describe, such as detailed trigger timing or guaranteed sustained throughput. Obtain the documented timing limits and validate the complete acquisition path.

Start with the camera configurator, or send your required feature list and capability-report format through application support. The useful deliverable is a repeatable configuration and verification procedure, not simply a list of maximum values.