Closed jveitchmichaelis closed 3 years ago
Hi! Great idea for an addition. It pains me to add more message types with such a small difference, but I think that in this case it definitely makes sense. It would be significant extra overhead to using vision_msgs
if you had to check each incoming message to see if it was compressed or not, and then pick the appropriate field. So CompressedDetection2D
etc. would be preferable.
I've been too busy recently to review PRs, but please go ahead and submit one and I will review it as soon as I can.
It'd be useful to support
CompressedImage
, as opposed to justImages
. This is convenient for a few applications e.g. in our case we're sending aDetection2DArray
over a socket toroslibpy
to display on a website and we'd need to re-encode the data as a jpeg/png otherwise. In general if you're sending tons of bounding box cutouts, sending the raw pixel data can add up to more bytes than the entire compressed image.I've tested this as a simple modification to
Detection2D
, which works fine. I'm happy to submit a PR for this if it'd be useful. Would a new message be preferable e.g.CompressedDetection2D
, or would an optional parameter toDetection2D
work instead?