Image message fields extension/cleanup

[Jakob Weiss]

I have several issues with the image data field:

To completely specify positioning of an image in 3D space, it should have an additional vector describing the pixel scaling of each axis - that way, together with the rest of the pose fields, it is possible to fully map from a pixel to 3D space even if there is non-uniform scaling, which is common for some modalities. This might already be stored with the image resolution field, but I cannot really find out what the supposed semantics are due to missing docs. If so, maybe this could be renamed to pixel scaling etc. for clarity, image resolution usually refers to the number of pixels in each dimension...

Furthermore, there are some fields which are unnecessarily signed:
width/height/depth/channels/image_size have no (obvious) need for a sign bit, so I would suggest making them unsigned unless there is some specific meaning related to negative numbers.

[Salvo Virga]

Just discussed with @goeblr about this. Indeed resolution is for us the image spacing (how distant pixels are along one direction).
We agree that in some other fields (say graphics 😺), the term might be interpreted as the image dimensions (width/height/depth), changing that to spacing sounds a good compromise.

As for the signed field, indeed they need to be changed!

[Salvo Virga]

I think I already had the fields width/height/depth as uint once, now I might remember why I opted for an int instead.

OpenCV cv::Mat ctor takes an int, using uint inside simple_msgs::Image for those fields we end up with a narrowing conversion warning when doing

simple_msgs::Image i = ...
const auto dimensions = i.getImageDimensions();
cv::Mat received_img{dimensions[1], dimensions[0], CV_8UC(i.getNumChannels()), img};

And since we build with -WError... 😃

[Salvo Virga]

I guess we just cast it for the examples and blame OpenCV 😈