use FourCC codes for image encodings

Feature request

The sensor_msgs/Image currently uses the encoding field to document how the raw data in the data field has to be interpreted. The fourcc (4 character code) is a 32bit integer formed by 4 ASCII characters, that uniquely describes the memory layout.

Feature description

The encoding field can contain an arbitrary text string, with some predefined strings in sensor_msgs::image_encodings. Those strings are not standardised and do not document the memory layout properly. The YUV formats even reference non-official documentation containing advertisements.

Instead of using these non-standard strings, I propose to rely on the fourcc widely used across the kernel and the userspace to uniquely and properly document the memory layout.

Implementation considerations

To support fourcc, either a uint32 or a char[4] field fourcc should be added to the sensor_msgs/Image message definition alongside the old encoding. To maintain backward compatibility, the logic could be that if encoding is empty, the fourcc would take the place as a definition of the memory layout.

Alternatively, the encoding string could also contain the fourcc alongside the "legacy" encodings. However, this would require an expensive string matching to test if encoding contains a fourcc or a "legacy" format encoding and it must be ensured that there are no collisions.

Start by reading the sensor_msgs/Image message definition and the sensor_msgs::image_encodings definitions mentioned in the issue. Compare the proposed uint32 or char[4] field with the legacy encoding behavior and backward-compatibility requirement. Done requires an agreed design and updated interface behavior, but the issue does not specify which alternative to implement.