Image transport plugins available as direct APIs in C, C++ and Python.
This library extends the ideas of image_transport to also provide C, C++ and Python APIs, as not all use-cases involving
image_transport automatically involve a running ROS system (e.g. bag file postprocessing).
With this library, you can decode and encode the compressed messages directly in your code with no need for a separate node just for this mundane work.
Or you can work with a particular codec directly if you know it at compile time. This should lead to highest performance.
If you wonder what is the type of
result, it is
cras::expected is a shim for
std::expected and expresses that the function either returns a value (in the expected case), or an error (in exceptional cases). So it has a lot of similarities to exceptions, however it doesn't come with the large performance penalties and unsure program flow.
First, let's settle on some terminology:
codecis a program that takes a raw image and converts it to a compressed byte stream, and vice versa
codec pluginis a pluginlib-style ROS plugin that registers a
codecso that it can be used via the generic interface explained in the first example in C++ section.
image_transport pluginis a widely used standard for plugins that ROS image publishers and subscribers can use to ease conversion of the various compressed formats
This library handles
codec plugins. There is unfortunately no way it could hook into classical
image_transport plugins and offer their functionality as a codec. Therefore, although the codec names are equal to the
image_transport names, so if you use custom
image_transport plugins, their functionality will not be available via this library out of the box. If you however do not mind some architectural changes, it would be best to base your
image_transport plugin on a
codec and expose also the corresponding
codec plugin. This way, the compression mechanism will be available via a Python, C++ and ROS API.
To provide a generic C++ API, the generic access via
ImageTransportCodecs class uses
ShapeShifters to represent the messages. Thus, each input compressed message is serialized before decoding, and each freshly compressed output image is serialized after being encodec. The same limitation applies to the C and Python APIs.
The direct C++ APIs (but only the C++ ones) mitigate this performance bottle-neck and are the only APIs that provide full performance.