Revision history [back]

In short, yes. There are multiple ways to approach this depending on how you want to handle the messages. You can always implement your own class that subscribes to both topics, stores the messages, and operates on them as you see fit. On the other end of the spectrum, you may be able to get away with using topic_tools (wiki) to republish the sensor_msgs/CompressedImage (doc), which does have a header, on a new topic and subscribing to that one with a message_filters::Synchronizer (wiki) as before. In between, you may be able to use the message_filter library to implement a custom filter without starting from scratch.

Please, provide more context if you'd like a more specific answer. How do you want to handle the messages if not time-synchronizing them? Do you need the unique_id for processing in the callback?

Update

To clarify the discussion in the comments, @Kansai chose the second option above. There is enough information in the original Image message defined in the question for normal synchronizing with a message_filters::TimeSynchronizer, but that info is not contained in a top-level header as expected.

The message definition contains a field called image of type sensor_msgs/CompressedImage, which in turn contains a header. The chosen solution therefore involves relaying the image field on its own (new) topic as a standalone CompressedImage message, which can work with the TimeSynchronizer.

To achieve the relay, one can use topic_tools/transform in a launch file like so:

<launch>
    <node name="pub" pkg="rostopic" type="rostopic"
        args="pub -r 1 /original_topic test_pkg/Image
            '{unique_id: 0, image: {header: {seq: 0, stamp: {secs: 1, nsecs: 0}, frame_id: 'test_frame'}, format: 'png', data: '[1]'}}'" />

    <node name="relay" pkg="topic_tools" type="transform"
        args="/original_topic /new_topic sensor_msgs/CompressedImage 'm.image'"/>
</launch>

Check output:

$ rostopic echo /new_topic 
header: 
  seq: 1
  stamp: 
    secs: 1
    nsecs:         0
  frame_id: "test_frame"
format: "png"
data: [1]
---

This way the allow_headerless option (which would use receipt time rather than a timestamp) is unnecessary, and better synchronization is possible. Though the relay node introduces some extra delay, it may be negligible for a given application. There are of course alternatives, but I don't want to clutter the discussion more if this solution works for OP.