ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question

Revision history [back]

Depends on the format. I store them as pcl::pointcloud. The data for one point is described in this header file, although it is somewhat cryptic. PointXYZRGB is described as follows:

00204 struct PointXYZRGB
00205 {
00206   PCL_ADD_POINT4D;  // This adds the members x,y,z which can also be accessed using the point (which is float[4])
00207   union
00208   {
00209     struct
00210     {
00211       float rgb;
00212     };
00213     float data_c[4];
00214   };
00215   EIGEN_MAKE_ALIGNED_OPERATOR_NEW
00216 } EIGEN_ALIGN16;

PCL_ADD_POINT4D and the union below will add 4 floats each. While that is overkill memorywise, it is required to benefit from some cpu optimizations. Therefore for a pcl::pointcloud<pointxyzrgb> from the kinect, you store 640 x 480 x 8 x sizeof(float) bytes.

I wonder why rgb is in a separate struct though. Does anybody know this.

Depends on the format. I store them as pcl::pointcloud. The data for one point is described in this header file, although it is somewhat cryptic. PointXYZRGB is described as follows:

00204 struct PointXYZRGB
00205 {
00206   PCL_ADD_POINT4D;  // This adds the members x,y,z which can also be accessed using the point (which is float[4])
00207   union
00208   {
00209     struct
00210     {
00211       float rgb;
00212     };
00213     float data_c[4];
00214   };
00215   EIGEN_MAKE_ALIGNED_OPERATOR_NEW
00216 } EIGEN_ALIGN16;

PCL_ADD_POINT4D and the union below will add 4 floats each. While that is overkill memorywise, it is required to benefit from some cpu optimizations. Therefore for a pcl::pointcloud<pointxyzrgb> pcl::pointcloud<pcl::PointXYZRGB> from the kinect, you store 640 x 480 x 8 x sizeof(float) bytes.

I wonder why rgb is in a separate struct though. Does anybody know this.

Depends on the format. The data payload is 640 x 480 x 8 x sizeof(float) bytes = 9830400 bytes

Plus some bytes for auxiliary information like origin, timestamp etc.

I store them as pcl::pointcloud. The data for one point is described in this header file, although it is somewhat cryptic. PointXYZRGB is described as follows:

00204 struct PointXYZRGB
00205 {
00206   PCL_ADD_POINT4D;  // This adds the members x,y,z which can also be accessed using the point (which is float[4])
00207   union
00208   {
00209     struct
00210     {
00211       float rgb;
00212     };
00213     float data_c[4];
00214   };
00215   EIGEN_MAKE_ALIGNED_OPERATOR_NEW
00216 } EIGEN_ALIGN16;

PCL_ADD_POINT4D and the union below will add 4 floats each. While that is overkill memorywise, it is required to benefit from some cpu optimizations. Therefore for a pcl::pointcloud<pcl::PointXYZRGB> from the kinect, you store 640 x 480 x 8 x sizeof(float) bytes.

I wonder why rgb is in a separate struct though. Does anybody know this.

For a PointCloud2 you can look at the message with rostopic echo -n 1 /camera/rgb/points| less. The interesting parts are:

height: 480
width: 640
point_step: 32

Therefore, also here you have 640 x 480 x 32, where 32 is 8 x sizeof(float)

The data payload is 640 x 480 x 8 x sizeof(float) bytes = 9830400 bytes

Plus some bytes for auxiliary information like origin, timestamp etc.

I store them as pcl::pointcloud. The data for one point is described in this header file, although it is somewhat cryptic. PointXYZRGB is described as follows:

00204 struct PointXYZRGB
00205 {
00206   PCL_ADD_POINT4D;  // This adds the members x,y,z which can also be accessed using the point (which is float[4])
00207   union
00208   {
00209     struct
00210     {
00211       float rgb;
00212     };
00213     float data_c[4];
00214   };
00215   EIGEN_MAKE_ALIGNED_OPERATOR_NEW
00216 } EIGEN_ALIGN16;

PCL_ADD_POINT4D and the union below will add 4 floats each. While that is overkill memorywise, it is required to benefit from some cpu optimizations. Therefore for a pcl::pointcloud<pcl::PointXYZRGB> from the kinect, you store 640 x 480 x 8 x sizeof(float) bytes.

I wonder why rgb is in a separate struct though. Does anybody know this.

For a PointCloud2 you can look at the message with rostopic echo -n 1 /camera/rgb/points| less. The interesting parts are:

height: 480
width: 640
point_step: 32

Therefore, also here you have 640 x 480 x 32, where 32 is 8 x sizeof(float)

A colleague of mine modified the openni_camera driver and rgbdslam to communicate the color value via the unused forth dimension of the pointXYZ. This essentially cuts the required memory to half the size. It is a little hackish, but if anyone wants the patch, you are welcome to contact me.

The data payload is 640 x 480 x 8 x sizeof(float) bytes = 9830400 bytes

Plus some bytes for auxiliary information like origin, timestamp etc.

A good way to check out the bandwidth required for transmission is rostopic bw

$ rostopic bw /camera/rgb/points
subscribed to [/camera/rgb/points]
(...)
average: 295.37MB/s
    mean: 9.83MB min: 9.83MB max: 9.83MB window: 100

To find the size in memory consider the following analysis:

I store them as pcl::pointcloud. The data for one point is described in this header file, although it is somewhat cryptic. PointXYZRGB is described as follows:

00204 struct PointXYZRGB
00205 {
00206   PCL_ADD_POINT4D;  // This adds the members x,y,z which can also be accessed using the point (which is float[4])
(...)
00207   union
00208   {
00209     struct
00210     {
00211       float rgb;
00212     };
00213     float data_c[4];
00214   };
00215   EIGEN_MAKE_ALIGNED_OPERATOR_NEW
00216 } EIGEN_ALIGN16;

PCL_ADD_POINT4D and the union below will add 4 floats each. While that is overkill memorywise, it is required to benefit from some cpu optimizations. Therefore for a pcl::pointcloud<pcl::PointXYZRGB> from the kinect, you store 640 x 480 x 8 x sizeof(float) bytes.

I wonder why rgb is in a separate struct though. Does anybody know this.

For a PointCloud2 you can look at the message with rostopic echo -n 1 /camera/rgb/points| less. The interesting parts are:

height: 480
width: 640
point_step: 32

Therefore, also here you have 640 x 480 x 32, where 32 is 8 x sizeof(float)

Optimization Hack

A colleague of mine modified the openni_camera driver and rgbdslam to communicate the color value via the unused forth dimension of the pointXYZ. This essentially cuts the required memory to half the size. It is a little hackish, but if anyone wants the patch, you are welcome to contact me.

me. The bandwidth reduction shown by rostopic bw

average: 148.35MB/s
        mean: 4.92MB min: 4.92MB max: 4.92MB window: 100

The data payload is 640 x 480 x 8 x sizeof(float) bytes = 9830400 bytes

Plus some bytes for auxiliary information like origin, timestamp etc.

A good way to check out the bandwidth required for transmission is rostopic bw

$ rostopic bw /camera/rgb/points
subscribed to [/camera/rgb/points]
(...)
average: 295.37MB/s
    mean: 9.83MB min: 9.83MB max: 9.83MB window: 100

To find the size in memory consider the following analysis:

I store them as pcl::pointcloud. The data for one point is described in this header file, although it is somewhat cryptic. PointXYZRGB is described as follows:

00204 struct PointXYZRGB
00205 {
00206   PCL_ADD_POINT4D;  // (...)
00207   union
00208   {
00209     struct
00210     {
00211       float rgb;
00212     };
00213     float data_c[4];
00214   };
00215   EIGEN_MAKE_ALIGNED_OPERATOR_NEW
00216 } EIGEN_ALIGN16;

PCL_ADD_POINT4D and the union below will add 4 floats each. While that is overkill memorywise, it is required to benefit from some cpu optimizations. Therefore for a pcl::pointcloud<pcl::PointXYZRGB> from the kinect, you store 640 x 480 x 8 x sizeof(float) bytes.

I wonder why rgb is in a separate struct though. Does anybody know this.

For a PointCloud2 you can look at the message with rostopic echo -n 1 /camera/rgb/points| less. The interesting parts are:

height: 480
width: 640
point_step: 32

Therefore, also here you have 640 x 480 x 32, where 32 is 8 x sizeof(float)

Optimization Hack

A colleague of mine modified the openni_camera driver and rgbdslam to communicate the color value via the unused forth dimension of the pointXYZ. This essentially cuts the required memory to half the size. It is a little hackish, but if anyone wants the patch, you are welcome to contact me. me. Keep in mind though, that linear algebra operations with Eigen might be affected by the color value or overwrite it. Haven't experienced that yet though. The bandwidth reduction shown by rostopic bw

average: 148.35MB/s
        mean: 4.92MB min: 4.92MB max: 4.92MB window: 100