A camera topic can exist and display correctly while a rectification node receives no usable image pair. Check the transport boundary before changing calibration: the publisher may send compressed bytes, while the subscriber expects decoded Image messages through a particular transport plugin. Remapping a name does not change a message type or decode its payload.
Trace one complete path from camera producer to decoder, rectifier input and rectified output. Record the actual endpoint types, resolved topic names, selected transport and paired CameraInfo. A working viewer proves that viewer’s path works; it does not prove another node uses the same subscription mechanism or plugin.
This workflow concerns image transport and subscription boundaries. It is separate from LiDAR network reception and from a geometrically incorrect overlay. Keep the ROS distribution and exact image_pipeline, image_transport and plugin package versions. Inspected development behavior below must be verified against the installed release, especially when investigating an older issue report.
Identify payload type at the actual endpoint
Inspect the topic the publisher advertises and the subscription the rectifier actually creates. The Image message definition describes an uncompressed pixel buffer with dimensions, encoding and row stride. That contract is different from a message carrying an encoded image file or transport-specific byte stream.
The CompressedImage definition carries a format field and compressed bytes whose interpretation depends on the transport. A compressed color image and compressed depth also have different conventions. Inspect the producer’s actual format rather than assuming every compressed payload can be handled by the same generic image decoder.
Write down whether each connection carries a base image topic or a derived transport endpoint. Names such as image, image_raw and compressed are clues, not type verification. A custom publisher can use an unusual name. Likewise, redirecting a plain Image subscription to a CompressedImage endpoint does not create a compatible decoder.
Check how the node selects its transport
The official image_transport tutorials explain base topics, transport plugins and transport-aware subscribers. Confirm which plugins are available in the actual runtime environment and how the deployed subscriber selects one. A package installed in another workspace or container does not establish availability for this process.
Inspect the loaded parameters and resolved names after launch overrides and namespaces. Distinguish a supported transport parameter from a parameter that a node accepts but never uses. Also check that remapping is applied to the base topic expected by that API, rather than appending a transport suffix twice or bypassing the transport mechanism.
The inspected development rectifier implementation declares a transport choice, resolves the base image topic and creates a transport-aware camera subscription. It also uses lazy subscription tied to output subscribers. Verify the installed code path; a historical report about hardcoded raw transport is not evidence that every release shares that behavior.
Connect a suitable observer to the intended rectified output when testing a node that subscribes lazily. Then inspect whether the input subscription appears and which endpoint it uses. Record the before-and-after graph rather than interpreting a topic listing alone. A publisher can advertise an output name without currently receiving or processing input data.
Validate decoding before rectification
When the transport-aware path is unclear, test the decode boundary independently in an isolated diagnostic namespace. Use the installed distribution’s supported republisher or decoder interface. Confirm that its output is a valid uncompressed Image stream with appropriate dimensions, encoding and original acquisition metadata before involving rectification.
Preserve the original compressed records and a short decoded sample. Compare the scene and timestamps, and inspect decoder diagnostics. Do not route a display-normalized preview into the rectifier as a substitute for the intended image stream. Keep test output names separate so a republisher cannot feed its own output back into its input.
A viewer may silently choose a plugin or transport option different from the rectifier’s configuration. Record the viewer settings as evidence about that path only. If the decoder fails, isolate format and plugin compatibility before changing camera intrinsics. If decoding succeeds, the next boundary is the image and CameraInfo pair rather than the compressed bytes.
Verify the paired camera information
The CameraInfo contract supplies calibration and acquisition metadata for the image stream. Check its namespace, timestamp, optical frame and relevant camera mode. An unrelated or absent camera-info stream can prevent a camera subscription from producing the pair needed for rectification.
Inspect calibration validity as well as arrival. The development rectifier cited above checks for an uncalibrated model before processing. Follow the actual diagnostic message and deployed implementation instead of assuming that every no-output condition means transport failure. Preserve both message headers and model fields when asking for help.
The sensor clock-check workflow helps identify timestamp-domain differences. The camera calibration workflow helps establish the model’s provenance. Neither a valid calibration file nor a current image alone proves that the subscriber receives a compatible pair.
Locate the first boundary without evidence
| Boundary | Evidence to inspect | Next decision |
|---|---|---|
| Producer to transport endpoint | Actual message type, format and resolved name | Choose a compatible subscription path |
| Transport to decoder | Loaded plugin, parameters and diagnostics | Resolve codec or plugin compatibility |
| Decoder to Image consumer | Decoded dimensions, encoding and headers | Establish an independent working image stream |
| Image plus CameraInfo | Paired acquisition metadata and model validity | Resolve missing or incompatible pairs |
| Rectifier to observer | Output subscription and processing diagnostics | Distinguish lazy subscription from failure |
Change one boundary at a time. Keep input records and launch configuration fixed while testing a supported transport selection or an isolated decoder. Once the pipeline receives matched decoded data, verify the rectified output independently before reconnecting downstream perception. A visible image establishes delivery, not geometric calibration quality or application readiness.
If endpoint types and decoding are correct but messages still do not arrive, inspect compatibility and middleware settings as a separate question. The ROS 2 QoS mismatch diagnostic explains the general publisher-subscriber distinction. Apply it to the actual image endpoints; a generic QoS change should not conceal an unresolved type mismatch.
Make the diagnostic path observable at each stage. Record when the decoder first produces a valid frame, when a compatible camera-info message is available, and when the rectifier callback actually processes a pair. Use supported diagnostics or a controlled development replay where those events are otherwise hidden. Do not equate an increasing publisher count with successful processing. When restarting one component, retain the launch order and whether an output observer was already attached, because lazy subscription can change the graph during startup. A useful report separates the advertised graph, the received messages and the processed output into distinct observations.
Common questions
Can I simply remap image to image/compressed?
Only when that is the interface expected by the actual transport-aware API. A name remap alone cannot convert compressed bytes into uncompressed pixels. Verify endpoint types and the installed subscriber implementation.
Does a working viewer prove the rectifier is configured correctly?
No. Viewers can select different transports and may not require the same camera-info pairing. Compare their paths explicitly instead of transferring the result from one to the other.
What makes a reproducible issue report?
Provide exact package versions, loaded parameters, resolved graph, endpoint types and short original records. The recording guide helps preserve timing, and the support bundle procedure organizes evidence. State the first boundary that lacks verified delivery rather than reporting only that the topic exists.
