ROS depth color compression mismatch: diagnose topic routing

A recording session can expose image-transport errors even when your inspection application works normally. The recorder may subscribe to advertised transport topics that your application never requests, activating compression paths with incompatible input encodings. That does not prove the camera streams are swapped or that recording changes their data. For an acquisition or integration engineer, the useful first step is to trace each image from its publisher through its transport subscribers. You can then record the required streams without confusing depth measurements with display images.

Read the errors as encoding evidence

Two complementary errors are especially useful: a depth compressor receives a color encoding, while a color-oriented conversion receives floating-point depth. These messages identify incompatible processing attempts, but not necessarily their cause.

For example, rgb8 describes three-channel, unsigned, eight-bit color. By contrast, 32FC1 describes a single-channel array of floating-point values. A conversion from floating-point depth to bgr8 is not a meaningful substitute for preserving the depth measurements.

Use this diagnostic order before changing the acquisition settings:

A topic name is only a label. Neither depth in a name nor an image_raw suffix proves what the message contains.

If the problem is instead a missing configuration control, use the separate guide to image-transport compression parameters. Here, the priority is identifying which messages reach which processing paths.

Inspect the graph before starting the recorder

The commands below use ROS 1 tools. The topic names are examples; replace them with names from your running graph. ROS 2 uses different command syntax and recording tools, although the same encoding and subscription checks apply.

Start with discovery and message inspection:

rostopic list
rostopic info /inspection/color/image_raw
rostopic info /inspection/depth/image_raw
rostopic type /inspection/color/image_raw
rostopic type /inspection/depth/image_raw
rostopic echo -n 1 /inspection/color/image_raw/encoding
rostopic echo -n 1 /inspection/depth/image_raw/encoding

Both raw topics will commonly use sensor_msgs/Image. That shared message type does not mean their pixel arrays are interchangeable. Inspect encoding, width, height and step, along with the header timestamp and coordinate-frame identifier.

An encoding query creates a subscriber. On a demand-driven publisher, even this brief inspection may activate acquisition or processing. Note exactly which command precedes an error.

Also inspect any relevant transport endpoint. Common naming patterns append /compressed or /compressedDepth to an image's base topic, but actual names depend on configuration.

Compressed endpoints commonly use sensor_msgs/CompressedImage. Ordinary compressed images and compressed depth can share that message type while requiring different decoding rules. Message-type agreement alone is therefore insufficient.

If a required source topic publishes nothing, first follow the stream-enable and topic-publishing checks, rather than treating absence as a compression fault.

Isolate subscription-triggered processing

A ROS 1 recorder normally subscribes to selected topics and stores the messages it receives. It does not need to decode raw pixels or create an image-transport conversion node to record them.

However, an image publisher can advertise transport alternatives whose processing starts only when subscribers appear. Recording every topic may activate several alternatives simultaneously. A plugin attached to a color image might then attempt depth compression, even though no launch remap crossed the color and depth streams.

Run a controlled sequence, returning to the same baseline between trials:

1. Run acquisition with only the inspection application's normal subscribers.
2. Record the raw color topic alone.
3. Record the raw depth topic alone.
4. Record both raw topics together.
5. If needed, request one compressed endpoint at a time using a matching consumer or an explicit recording selection.

Save the first error, its emitting node and the subscriber change that immediately preceded it. If both raw streams remain valid and errors appear only when incompatible transport endpoints receive subscribers, investigate transport activation before rewriting topic routing.

Conversely, if the error persists with record-all capture stopped, inspect existing viewers, relays and republishers. The recorder may merely have revealed an already incorrect subscription.

Correct routing without changing measurement meaning

Inspect the nodes associated with the failing paths using rosnode info, alongside the publisher and subscriber lists from rostopic info. Check resolved topic names rather than only the names written in a launch file.

A namespace, relative topic name or copied remap can connect an otherwise correct component to the wrong image. Confirm the base image, selected transport and expected encoding at every relay boundary.

Common compressed-depth implementations accept 16UC1 and 32FC1, but verify the installed implementation and its supported formats. Those encodings describe storage; they do not independently establish the physical depth units.

Do not assume every ordinary compressed transport is unsuitable for every depth array. Some configurations can carry unsigned depth through PNG. That is a different claim from preserving floating-point depth or supporting a particular compressed-depth decoder.

Never fix a measurement pipeline by casting floating-point depth to an eight-bit display image. Generate a separate visualization topic instead. For display-only issues, consult the depth-image format and color-conversion guide.

Record an explicit set of required topics

For diagnosis, prefer a topic allowlist over recording everything and then adding broad exclusions. An allowlist makes the subscription change visible and reproducible.

After confirming that the example topics exist, a short raw acquisition test could be:

rosbag record --duration=10 -O raw_check \
  /inspection/color/image_raw \
  /inspection/depth/image_raw \
  /inspection/color/camera_info \
  /inspection/depth/camera_info

Include the actual calibration topics used by your driver. If downstream processing depends on coordinate transforms, also capture the relevant transform topics and verify that static transforms are present in the recording.

Start the recorder before requesting a service-triggered acquisition. Then confirm it has subscribed before initiating the capture. Otherwise, a short capture can finish before the recorder is ready.

There are two separate compression decisions:

• Image-transport compression changes the messages published on a transport endpoint and can involve encoding conversions.
• Bag-file compression compresses the recorded storage chunks without asking an image-transport plugin to reinterpret their pixels.

Bag compression can reduce storage consumption, but its CPU load and compression ratio still need testing. It does not correct an invalid image-transport connection.

For selecting the measurement content and metadata to retain, follow the guide to recording depth data losslessly. Avoid recording raw images and every derived transport unless each copy has a defined purpose.

Calculate raw recording load before a longer run

Removing transport errors does not prove that the recorder can sustain the incoming data rate. Estimate the raw payload before increasing capture duration.

For tightly packed images with equal dimensions and rates:

Consider separate color and depth streams, each delivering 640 × 480 images at 30 frames per second. Assume color uses rgb8 and depth uses 32FC1.

• Color payload: 640 × 480 × 3 × 30 = 27,648,000 bytes/s.
• Depth payload: 640 × 480 × 4 × 30 = 36,864,000 bytes/s.
• Combined payload: 27,648,000 + 36,864,000 = 64,512,000 bytes/s.
• Ten seconds of pixel payload: 64,512,000 × 10 = 645,120,000 bytes.

That is approximately 64.5 MB/s and 645 MB respectively, using decimal units. It excludes message headers, calibration, transforms, file overhead and other recorded topics.

If rows contain padding, use step × height × frame rate instead. Point clouds can add substantial traffic beyond these image arrays.

This calculation predicts storage demand, not guaranteed recorder performance. Monitor actual message delivery and write behavior under the intended workload. Once correctness is established, the guide to reducing depth recording file size covers retention choices without confusing them with routing repairs.

Verify the recording through replay

Inspect the completed file before changing compression settings:

rosbag info raw_check.bag

Check that the selected topics contain messages and that their duration matches the capture procedure. For a service-triggered camera, the expected count follows the number of requested acquisitions, not an assumed continuous frame rate.

Replay with the live acquisition publisher stopped or isolated in a separate namespace. Otherwise, a subscriber might receive messages from both the recording and the live device.

Acceptance checks should include:

• Raw color and depth messages retain their expected encodings and dimensions.
• Calibration messages and required transforms are available to the replay consumer.
• Header timestamps and coordinate-frame identifiers remain usable by downstream processing.
• Depth units and invalid-pixel handling match the processing configuration.
• Measurement software consumes the depth array, not a colorized preview.
• No new conversion error appears when the intended consumers connect.

Do not infer synchronization merely because two topics are in the same file. If downstream inspection combines color and depth, check the driver's timestamp relationship and alignment information separately.

Only after raw replay works should you evaluate a compressed transport. Compare decoded measurements against the raw reference using your inspection's precision requirement, including invalid values and any quantization introduced by the chosen method.

Check software compatibility before replacing hardware

An encoding mismatch is usually a software-path question before it is a hardware-selection question. Record the ROS distribution, driver, image-transport plugins and image-bridge versions, together with the launch configuration that reproduces the fault.

If behavior differs across machines, reproduce the same topic allowlist and package set first. Obtain driver updates and camera firmware through the manufacturer or its authorized distribution channels. Change one component at a time and repeat the raw-recording test.

If you are also selecting hardware, compare 3D sensors by the required measurement method and documented output support. The projected structured-light option is a catalog starting point for that discussion, not evidence of a particular ROS driver or transport implementation.

For a separate color acquisition path, review area scan cameras and the USB3 area scan option. Verify driver availability, timestamps and calibration requirements independently; adding a camera does not automatically align its images with depth.

Use the camera finder for hardware selection after the required outputs are defined. Do not replace a functioning acquisition device merely because an unused transport endpoint rejects its encoding.

Prevent the fault from returning

Keep a short acquisition manifest with the deployment configuration:

• List each recorded topic, message type, encoding and purpose.
• Identify which subscribers activate optional processing.
• Keep measurement depth separate from display previews.
• Save the tested transport selections and package versions.
• Validate raw recording and replay before enabling compression.
• Retest with the intended recording load after configuration changes.

The quickest recovery is often an explicit raw-topic recording, followed by a targeted transport correction. When that test fails, its smaller graph also gives support a clearer reproduction.

For an existing system, bring the topic manifest, first error and package versions to application support. For a new acquisition system, start with the camera configuration step and specify the required depth and color outputs before choosing parts.