Adding support for CompressedImage ros message and corresponding element

[KhanMechAI]

We needed compressed images, so I did my best to add it. Probably not perfect, open to feedback, but its working for me.

In my fork i deleted the plugins folder due to issues with the webrtc stuff, the meat and potatoes is here.

[BrettRD]

Thanks for the PR!
This approach avoids the one publisher per format thing I've been worrying about, are you using this with ImageTransport?
The ImageTransport docs are far too sparse for me to tell how close this gets to interoperability.

It seems a bit like this plugin would only need to to pull the ImageTransport format metadata list from ROS to support third-party ImageTransport compression plugins, and a corresponding src element could be backed by a gstreamer decodebin.

I see a lot of people trying to use ROS+DDS for transport when gstreamer has a lot of extremely competent compression and transport options, have you experimented with using gst_pipeline in a ComposableNodeContainer on both sides of the network? I've found RTP headers for precise timing metadata to be especially helpful.

A COLCON_IGNORE in the plugins folder might help you reduce fork divergence for now, I'll probably split the repo if this gets a full release.

Cheers

[KhanMechAI]

Hey! Thanks for looking at this so quick.

So the use case for us is actually to not use image_transport. It's running on NVIDIA hardware with hw encoders and decoders we wanted to push the processing out to (nvv4l2h264enc/dec, nvjpegenc/dec).

We were using the gst_node with image_transport you mention in your docs, but it was hammering the cpu and it's just a bit too opaque with what's going on, and a real pain to build with NVIDIA hardware. Found your project and it was almost perfect. Also not so easy to build with NVIDIA stuff but we got there. This is likely where the cause of the webrtc compatibility issues are, as Jetpack 5.4.1 runs Ubuntu 20.04, and Humble is for 22.04. So I didn't want to raise an issue for a pretty niche use case, one that we might not have to deal with after an update anyways.

COLCON_IGNORE is a great suggestion, my ROS is very limited. I haven't dabbled with the gst_pipeline yet, but the composable nodes are definitely worth a look from my perspective. Agreed, Gstreamer is already pretty battle tested, so I think it's a good fit for much of the multimedia transport.

[BrettRD]

I had heard that Jetpack was running an ancient distro, I didn't realise that hadn't had any maintenance.
I'm still waiting for more modern gst webrtc features to land in a default distro to make the webrtc features here properly useful.
The recent rust elements webrtcsrc and webrtcsink are incredibly easy to use and have modular signalling protocols

I would like achieve proper interoperability with ImageTransport but with compression offloaded upstream into gstreamer like you've configured here. This method also applies all the way down to the raspberry pi zero where the tiny gpu h264 compresses the mipi camera.
I'll definitely refer back to this if anyone else needs a gpu-offloaded ImageTransport API.

I have a config string for H264>RTP>UDP in the readme, if you put the udp reciever in a composable node with the rest of your CV nodes, you can pull the uncompressed messages out of gstreamer as shared-pointers into downstream ros nodes.
Using the gst_pipeline will let you adjust the bitrate on the fly using ros parameters