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.
If using the receipt time instead of a timestamp is acceptable (depends on your application),
allow_headerless = Trueshould work, and you can post your code for help troubleshooting. Otherwise, there's no need to modify the publisher directly. If you're really trying to synchronize the messages, theimagefield of yourImagemessage, should have a header in it as I mentioned below, which is probably what you should use.I have checked and the image field does seem to have a header filled. I am now learning how to use topic_tools relay to republish... it seems it can be done by a launch file but I wonder if that is possible from the code? mmm it seems relay will only republish the same message... wonder how to publish only the image part...
@tryan is there a way to synchronize it with the header of the image part of the message?
You could do that if you write a custom message filter, but it would probably be easier to write a node (if topic_tools doesn't work) to republish a message you can use with an existing filter.