ROS image transport recording: keep depth data reliable

A camera can publish usable images until recording starts, then produce transport errors, irregular depth updates, or an almost empty point-cloud recording. The recorder may be subscribing to more than the images you actually need, activating additional compression work along the way.

This troubleshooting procedure separates acquisition failures from transport-plugin failures. It focuses on ROS 1 commands: identify the native streams, record an explicit topic list, disable unnecessary publishers where supported, and verify the recording against a measured baseline. ROS 2 uses different recording commands and configuration mechanisms.

Identify which stream is actually failing

Start by separating the sensor stream, its transport variants, and downstream processing. These are related, but they are not interchangeable.

A topic ending in image_raw is not proof of any particular encoding. Inspect the message rather than inferring its contents from the name.

A depth-compression error mentioning a color encoding points toward an inappropriate transport being applied to that image. It does not, by itself, prove that the native depth stream has stopped.

Likewise, a missing point cloud does not establish a camera failure. Its processing node may lack depth images, calibration, transforms, or matching color timestamps. For depth-specific display failures, use the separate procedure for depth image display and color-conversion errors.

Step 1: inventory topics before starting a recorder

Close unnecessary image viewers and stop existing recorders. Other subscribers can activate processing and obscure the baseline.

1. List the available topics and identify their publishers.
2. Inspect the message type of each required topic.
3. Read the image encoding and measure the raw publication rate.
4. Record the camera configuration and relevant software versions before changing anything.

These example names are illustrative. Replace them with topics actually published by your installation:

rostopic list
rostopic info /camera/depth/image_raw
rostopic type /camera/depth/image_raw
rostopic echo -n 1 /camera/depth/image_raw/encoding
rostopic hz /camera/depth/image_raw
rostopic bw /camera/depth/image_raw

Repeat the checks for color and infrared streams. Allow the rate measurement to settle over several seconds rather than relying on its first estimate.

Distinguish image payloads from transport containers. Native images commonly use sensor_msgs/Image; compressed variants commonly use sensor_msgs/CompressedImage. A different message type is not automatically proprietary or defective.

The encoding 16UC1 describes unsigned, single-channel integer storage. It does not independently establish the physical depth scale. Confirm units and invalid values in the driver's documentation. Similarly, do not convert an infrared intensity image into a color format merely to satisfy an unrelated encoder.

If expected controls are absent, follow image transport compression parameter troubleshooting before adding parameters copied from another installation.

Step 2: record an explicit set of native topics

An all-topic recording can discover and subscribe to advertised transport variants as well as native images. Some image transport publishers activate their encoding work when a subscriber connects. Consequently, starting a recorder can change the workload rather than simply observe it.

Begin with the smallest useful recording:

rosbag record --duration=60 -O depth_baseline.bag /camera/depth/image_raw /camera/depth/camera_info

Then add color images and their calibration information:

rosbag record --duration=60 -O selected_capture.bag /camera/depth/image_raw /camera/depth/camera_info /camera/color/image_raw /camera/color/camera_info /tf /tf_static

Use the transform topics only when your processing depends on them. Verify that required static transforms actually appear in the recording; their existence in a running system is not sufficient evidence.

Add infrared images only when the intended analysis needs them. Record a point cloud when it is itself a required output, not simply because it is advertised. Reconstructing a cloud later may be possible if you retain the required images, calibration, transforms, timing, and processing configuration.

An explicit list is usually easier to audit than an exclusion expression. If an all-topic recording is mandatory, test its exclusion rules against the complete topic list. Regular-expression mistakes can silently retain unwanted transports or omit necessary data.

For the broader choice between original depth samples and processed outputs, see recording depth data losslessly for offline analysis.

Step 3: disable unwanted transport publishers where supported

Excluding a topic from a bag stops that recorder subscribing to it. It does not remove the publisher, and another subscriber can still activate it.

Some ROS 1 image transport implementations support a disable_pub_plugins parameter beneath the base image topic. Where your installed implementation documents this mechanism, configure it before the image publisher is created.

For example, a configuration might disable unnecessary transports for a native depth publisher:

/camera/depth/image_raw/disable_pub_plugins:
  - image_transport/compressed
  - image_transport/compressedDepth
  - image_transport/theora

This example deliberately retains only the native image path. Disabling compressedDepth is appropriate here because the recording strategy uses raw depth, not because depth compression is inherently unsuitable.

Load the configuration before launching the camera publisher, using your normal launch configuration or parameter-loading process:

rosparam load transport_disable.yaml

Confirm the exact parameter namespace, supported mechanism, and plugin identifiers against the installed package documentation. Do not assume that another driver release exposes identical controls.

After restarting the relevant publisher, check that the parameter exists and inspect the advertised topics again:

rosparam get /camera/depth/image_raw/disable_pub_plugins
rostopic list

Apply equivalent settings separately to other base image topics when needed. Configuring the depth topic does not necessarily affect color or infrared publishers.

A successful parameter lookup only proves that the parameter server contains a value. The practical test is whether the restarted publisher honors it and unnecessary transport topics disappear.

Step 4: estimate the recording load before adding outputs

Use payload arithmetic to distinguish a plausible throughput problem from an encoding mismatch. For an uncompressed image, the first estimate is:

Consider an illustrative acquisition with color, depth, and infrared images. Each image is 640 × 480 pixels at 30 frames per second. Assume color occupies 3 bytes per pixel, depth occupies 2, and infrared occupies 1.

The estimated rates are:

• Color: 640 × 480 × 3 × 30 = 27,648,000 bytes/s.
• Depth: 640 × 480 × 2 × 30 = 18,432,000 bytes/s.
• Infrared: 640 × 480 × 1 × 30 = 9,216,000 bytes/s.
• Combined: 55,296,000 bytes/s, approximately 55.3 MB/s using decimal units.

Over 60 seconds, those image payloads alone occupy approximately 55.3 × 60 = 3,318 MB, or 3.32 GB. This excludes message metadata, bag indexing, transforms, and filesystem overhead.

A dense point cloud can add substantially more traffic. If an illustrative cloud stores 16 bytes per point at the same dimensions and rate, its payload is 640 × 480 × 16 × 30 = 147,456,000 bytes/s. Actual cloud layouts vary, so inspect point_step, row_step, and dimensions rather than assuming this layout.

Compression can reduce storage traffic while increasing processor demand. Lossless bag-container compression is also different from image transport compression: it compresses stored messages without requiring a depth image to become a color image.

For storage-focused changes after acquisition is stable, use reducing depth recording file size without losing usable data.

Step 5: verify counts, timestamps, and downstream recovery

A bag file that opens successfully is not necessarily a complete recording. Check the stored topics first:

rosbag info selected_capture.bag

For every required stream, inspect message count, recording coverage, image dimensions, and encoding. Then examine image header timestamps using a bag reader or analysis tool.

At a measured 30 frames per second over 60 seconds, the nominal count is 30 × 60 = 1,800 images. Recording boundaries and startup behavior can change the observed count, so compare against the measured publication rate and the actual capture interval.

Do not require identical counts from streams configured at different rates. Calibration and transform topics also need not publish once per image.

Use a staged test sequence:

1. Measure native publication with no recorder.
2. Record depth and its calibration only.
3. Add color and required transforms.
4. Add infrared if required.
5. Add registration or point-cloud outputs last.

At each stage, compare header intervals, recorded counts, processor load, and sustained storage traffic. At 30 frames per second, the nominal timestamp interval is 1 / 30 = 0.0333 seconds, approximately 33.3 ms.

Define acceptable losses before testing. For example, an application might flag intervals exceeding twice the nominal period for investigation. That is a diagnostic threshold, not a guarantee that every such interval represents a lost exposure.

Header timestamps describe acquisition timing according to the driver's timestamp convention. Bag timestamps describe recorded message timing and can differ. If playback speed or duration appears wrong despite plausible frame counts, follow camera recording timing-error diagnosis.

For paired color and depth processing, also verify timestamp relationships rather than matching images solely by array position. The procedure for asynchronous frame matching with timestamps explains that distinction.

Separate software symptoms from acquisition hardware faults

Use the stage at which failure begins to choose the next test.

Do not interpret every device timeout as a compression fault. Preserve driver logs and determine whether the timeout occurs without transport subscribers. Use software, firmware, and diagnostic utilities obtained from the manufacturer or its authorized distributors.

For separate machine-vision acquisition work, area scan cameras can be filtered through the camera finder. The LS-CMR-0053 and LS-CMR-0166 provide examples of GigE and USB3 acquisition options respectively. They are not presented as stereo-depth replacements or as confirmed ROS-compatible devices.

For a host requiring an acquisition interface, review frame grabbers through the accessory finder. The LS-FGB-0004 is a Gigabit Ethernet card; its presence does not correct an image transport configuration error.

Before changing an acquisition card, check the relevant driver and host requirements. For interfaces that require dedicated acquisition hardware, the guide to frame grabber image acquisition provides the appropriate integration checks.

Final recording checklist

Before accepting a production recording configuration:

• Confirm every native image's encoding rather than trusting its topic name.
• Document depth units, invalid values, calibration, and frame identifiers.
• Keep only the native and derived outputs required by the task.
• Verify that unwanted transport publishers are disabled or have no unnecessary subscribers.
• Measure frame rates before recording and compare them with stored counts afterward.
• Check header timestamp gaps and required inter-stream timing relationships.
• Confirm calibration and transforms are present in the bag.
• Replay the bag into the intended processing pipeline without the camera connected.
• Retain the topic list, launch configuration, and software versions with the capture.

The usual recommendation—record native images first—is not always the final deployment choice. A validated compressed transport may be necessary for a constrained link, while some workflows require derived point clouds exactly as produced online. Add those outputs deliberately and repeat the same measurements.

If native acquisition remains unstable after isolating transport and recording load, use technical support with the topic inventory, encodings, baseline rates, bag counts, and logs. For a new acquisition system, start with the camera configurator after defining the required streams and sustained data rate.