Camera Inventory Reading: Devices, Sensors and Profiles

Camera Inventory entries can become misleading when a software list is treated as a count of physical cameras. RealSense SDK documentation describes devices, sensors and stream profiles at different levels. A device can expose sensors, and a sensor can provide a list of possible stream profiles. Reading those lists together helps an equipment editor describe what a supplied report actually enumerates. This article interprets existing documentation and a fictional inventory appendix; it connects to no camera and performs no discovery, configuration or streaming.

Locate the physical-camera device level

The official RealSense device C API header describes its device object as representing a physical camera. It separately defines the device count for a device list. A report headed device count should preserve that object and the circumstances in which the list was obtained. A count copied from a different list needs its own label rather than automatically becoming another camera count.

For a fictional equipment catalogue, suppose a contributor supplies one device entry followed by several nested sections. The editor should retain the parent-child structure in the appendix. Flattening every section into a new camera row would discard the relationship that explains the report. Conversely, a documentation example showing this structure does not establish how many cameras are actually installed in any particular robot cell.

Keep sensors attached to their parent device

The same header describes rs2_query_sensors as creating a static snapshot of the connected sensors within a particular device. The sensor C API header supplies a separate sensor-list count and sensor objects. Its stream-profile function refers to a sensor as a physical subdevice. These are related API objects, but their lists answer different enumeration questions.

Consequently, a sensor subtotal belongs beneath its identified device. It should not be added to the device total as if it were a second shipment of cameras. An equipment summary can preserve the original hierarchy without attempting to reconstruct the camera's internal hardware arrangement from names alone. The SDK description explains the API relationship; the actual submitted report still needs to identify which device its sensor sections concern.

Read profiles as stream-configuration alternatives

The sensor header describes rs2_get_stream_profiles as returning the profiles that the given subdevice can provide. Its profile-data accessor identifies stream type, data format, stream index and expected frame rate. A video-profile accessor separately describes width and height. A profile row therefore carries stream-configuration information. Several such rows can describe alternatives associated with the same parent sensor, rather than several additional physical cameras.

A fictional appendix might repeat a stream type with different profile details. The useful catalogue description preserves those alternatives and their parent sensor. It does not rename each row an installed sensor or a delivered camera. The complete profile identity also matters when comparing two supplied lists: a shortened label such as depth can conceal differences that remain visible in the original profile records.

The expected frame-rate field is part of that profile description. Its presence in a supported-profile table does not report a measured delivery rate from a robot application. Similarly, video dimensions attached to an available profile do not prove that a particular saved image used that profile. A contributor would need to connect the actual record to the claimed configuration before an editor could describe that relationship.

Separate available profiles from active acquisition

The header gives opening a sensor with a selected profile, opening a composite configuration and starting streaming their own API descriptions. The distinction supports a limited reading rule: the list of profiles a sensor can provide is not itself a record that all listed profiles were simultaneously acquired. Nothing here calls those functions or recommends a profile combination.

If a contributor claims simultaneous acquisition, a supported-profile list alone leaves an evidence gap. A review note can ask which profiles were selected together and what retained record supports the acquisition claim. It should leave that question open when only capability material is available. Counting every alternative as an active stream would silently replace a configuration catalogue with an observation that was never supplied.

Preserve the hierarchy in the published inventory

A clear equipment entry can name the device-level record, nest the sensor records and retain the associated profile alternatives under each sensor. The source revision matters because these references use the SDK repository's mutable master branch, read for this article on November 5, 2026. They are API documentation, rather than a model-specific promise that every camera exposes the same sensors or profiles.

When an inventory is revised, distinguish an editorial restructuring from new discovery evidence. Moving profile alternatives into nested rows changes the presentation, while a new supplied report may change the documented contents. Keeping that distinction visible allows a later reader to understand why a total changed without inventing a camera installation or removal event.

The original diagrams summarize document relationships and contain no actual inventory counts. Related material appears in the equipment information category and component reference category. A useful Camera Inventory preserves the level at which each list was defined, so device, sensor and profile entries remain understandable when the source appendix is condensed.