Understanding the bytes in a pcl2 message
I am using python in order to publish pointclouds. Prior to this I'd like to run some segmentation using python-pcl and colorize each cluster. Unfortunately, the only function that creates a pcl message from a numpy array does so without considering color (only x, y, z).
pcl2.create_cloud_xyz32(header, nx3_numpy_array)
Therefore, I want to create a ros message then tweak it manually to change the color of each point. Here is an example message:
header:
seq: 1535
stamp:
secs: 1524593497
nsecs: 322609179
frame_id: "gripper_depth_camera_rgb_optical_frame"
height: 480
width: 640
fields:
-
name: "x"
offset: 0
datatype: 7
count: 1
-
name: "y"
offset: 4
datatype: 7
count: 1
-
name: "z"
offset: 8
datatype: 7
count: 1
-
name: "rgb"
offset: 16
datatype: 7
count: 1
is_bigendian: False
point_step: 32
row_step: 20480
data: [0, 0, 192, 127, 0, 0, 192, 127, 0, 0, 192, 127, 0, 0, 0, 0, 0, 0, 0, 255, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
It is easy to understand why x, y and z require 4 bytes each (float 32)
But why does rgb come at 16 and not 12? following the logic, z also needs 4 bytes, and the next free spot is at an offset of 12 and not 16.
Also why does rgb need 16 bytes? (point_step is 32 so one point requires 32 bytes from which 16 are for rgb). The color values themselves need only one byte each so this is confusing. Also, if we say the are float32 values, 16 bytes means 4 values, is the fourth value the transparency (RGBA?)
Here is an example from an XYZ only pointcloud where my understanding fits:
header:
seq: 5
stamp:
secs: 1524583199
nsecs: 372246980
frame_id: "gripper_depth_camera_rgb_optical_frame"
height: 1
width: 231
fields:
-
name: "x"
offset: 0
datatype: 7
count: 1
-
name: "y"
offset: 4
datatype: 7
count: 1
-
name: "z"
offset: 8
datatype: 7
count: 1
is_bigendian: False
point_step: 12
row_step: 2772
data: [125, 207, 94, 190, 220, 24, 98, 190, 254, 67, 60, 63, 69, 231, 92, 190, 6