ROS2 compatible image message #695
Conversation
|
|
||
| compatImage.getHeader().getStamp().setSec((int) imageToPublish.getAcquisitionTime().getEpochSecond()); | ||
| compatImage.getHeader().getStamp().setNanosec(imageToPublish.getAcquisitionTime().getNano()); | ||
| compatImage.getHeader().setFrameId(Long.toString(imageToPublish.getSequenceNumber())); |
There was a problem hiding this comment.
I don't understand the frame_id thing :(
| PixelFormat pixelFormat = PixelFormat.fromImageMessage(imageMessage); | ||
| System.out.println("pixelFormat " + pixelFormat.name()); | ||
| // TODO: set encoding |
There was a problem hiding this comment.
This is the tricky part... seems like the Image message is limited to RGB, RGBA, BGR, BGRA, MONO8, and MONO16 (GRAY8 and GRAY16 in our PixelFormat).
It also supports OpenCV types as encodings, but it seems like the isColor() and isMono() functions will return false for all OpenCV types (even if it's 16UC1, which should be identical to MONO16). So I'm not sure if nvblox will be happy with an OpenCV type.
So, these are possible solutions:
- Only allow images of RGB, RGBA, BGR, BGRA, GRAY8, and GRAY16 pixel formats to be passed in. Assign the encoding with a switch statement. Throw exception if an image of some other pixel format is passed in.
- Allow all images to be passed in. If it's RGB/A, BGR/A, GRAY8/16, assign the correct encoding. Otherwise attempt to convert the image to RGBA (PixelFormat has a method for that, though it doesn't work with some pixel formats). This will be slower if someone is passing in, say, YUV images.
- Just use the OpenCV type and hope nvblox doesn't mind that. Maybe internally it assumes 8UC3 = RGB, 16UC1 = depth or something. Pretty sure it'd just be a bit switch statement.
I vote for option 1!
| // TODO: set encoding | ||
|
|
||
| compatImage.setIsBigendian((byte) 0); | ||
| // compatImage.setStep(0); |
There was a problem hiding this comment.
Pretty sure this'll be:
| // compatImage.setStep(0); | |
| compatImage.setStep(imageToPublish.getCpuImageMat().step()); |
| // TODO: This is probably slow | ||
| byte[] imageData = new byte[compatImage.getData().capacity()]; | ||
| imageToPublish.getCpuImageMat().data().put(imageData); | ||
| compatImage.getData().add(imageData); |
There was a problem hiding this comment.
Wrap the underlying ByteBuffer of compatImage in a Pointer object and use Pointer::memcpy?
| @@ -102,6 +110,32 @@ private void publishAsImageMessage(ROS2Topic<ImageMessage> imageTopic, RawImage | |||
| ros2Helper.publish(imageTopic, imageMessage); | |||
| } | |||
|
|
|||
| private void publishAsROS2CompatImage(ROS2Topic<ROS2CompatImage> imageTopic, RawImage imageToPublish) | |||
| { | |||
| ROS2CompatImage compatImage = new ROS2CompatImage(); | |||
There was a problem hiding this comment.
Might be better to make this guy a field (slight memory allocation optimization)
|
|
||
| uint8 is_bigendian # is this data bigendian? | ||
| uint32 step # Full row length in bytes | ||
| uint8[<=5000000] data # actual matrix data, size is (step * rows) |
There was a problem hiding this comment.
This is enough for 1280 x 720 RGBA image but not enough for 1920 x 1080. Good enough for now, unless we want to increase the ZED's resolution (which we might want to do, since Arghya is training YOLO models at 1080p now?)
No description provided.