BrettRD / ros-gst-bridge

a bidirectional ros to gstreamer bridge and utilities for dynamic pipelines
Other
128 stars 30 forks source link

Extend encodings to support sensor_msgs::image_encodings::TYPE_16UC1 #58

Closed bastianhjaeger closed 4 months ago

bastianhjaeger commented 9 months ago

I would like to extend the encoding to support 16UC1 encodings (for realsense depth iamges).

If I manually change gst_bridge.cpp#L33-L57 by

sed -i 's/MONO16/TYPE_16UC1/g' gst_bridge/src/gst_bridge.cpp

everything works for me.

How could I extend the current code to support MONO16 and TYPE_16UC1? I am not sure how to resolve the ambiguous conversion in std::string getRosEncoding(GstVideoFormat format) from GST_VIDEO_FORMAT_GRAY16_LE to either MONO16 or TYPE_16UC1

Theoretically:

  if (format == GST_VIDEO_FORMAT_GRAY16_LE) {return sensor_msgs::image_encodings::MONO16;} 
  if (format == GST_VIDEO_FORMAT_GRAY16_LE) {return sensor_msgs::image_encodings::TYPE_16UC1;} 

Any insights? I could do the coding.

BrettRD commented 9 months ago

I can't quite figure out what you're asking for, Are you having trouble getting the imagesink to emit a specific type string for downstream tools? or are you having trouble getting imagesrc to recognise the format coming out of a realsense?

if it's the imagesink, you can override the type to an explicit string using the ros-encoding property If it's the imagesrc, you can give it a caps-filter specifying the gstreamer type to bypass the auto-detect