PointXYZRGB

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

PointXYZRGB

Mike Sokolsky
I'm a little confused at the definition of PointXYZRGB - it declares a float rgb field for the color data... I suppose you could pack the data in and use a reinterpret_cast to read it out, but since the PointXYZRGBA structure defines the field as a uint32 it seems like it could just be a bug.

Also, would it make sens to provide a definition similar to POINT4D with a union of the uint32 and four 8-bit types for x,y,z,a?  Or is there already a standard way to handle colors in ROS?  Thanks.

Cheers,
Mike

_______________________________________________
[hidden email] / http://pcl.ros.org
https://code.ros.org/mailman/listinfo/pcl-users
Reply | Threaded
Open this post in threaded view
|

Re: PointXYZRGB

Radu B. Rusu
Administrator
Yeah, traditionally this is how ROS started:

136           uint8_t g = color.at<uint8_t>(u,v);
137           int32_t rgb = (g << 16) | (g << 8) | g;
138           points.channels[0].values.push_back(*(float*)(&rgb));

[code copied from stereo_image_proc]

:)

I agree with your assessment about uint32t. The problem was that for the first PointCloud.msg (which is not even
supported in PCL), everything was a float, so things were just horrible.

I'm not sure what you mean with POINT4D. Are you referring to a message in ROS being called that way that could provide
those values? I think there is no support for that in ROS. PCL is fine, but other pieces of code might make use of that
too. However the overhead could be large (do you need a header for each point, etc?).


The standard way to handle colors in ROS right now is still the one that I mentioned above. This is one of the reasons
why when you downsample something using pcl::VoxelGrid, the downsampled colors look bad. I guess we can add an _if_ in
that loop and treat this as a special case...

Cheers,
Radu.

On 10/12/2010 04:14 PM, Mike Sokolsky wrote:

> I'm a little confused at the definition of PointXYZRGB - it declares a
> float rgb field for the color data... I suppose you could pack the data
> in and use a reinterpret_cast to read it out, but since the PointXYZRGBA
> structure defines the field as a uint32 it seems like it could just be a
> bug.
>
> Also, would it make sens to provide a definition similar to POINT4D with
> a union of the uint32 and four 8-bit types for x,y,z,a?  Or is there
> already a standard way to handle colors in ROS?  Thanks.
>
> Cheers,
> Mike
>
>
>
> _______________________________________________
> [hidden email] / http://pcl.ros.org
> https://code.ros.org/mailman/listinfo/pcl-users
_______________________________________________
[hidden email] / http://pcl.ros.org
https://code.ros.org/mailman/listinfo/pcl-users
Reply | Threaded
Open this post in threaded view
|

Re: PointXYZRGB

Mike Sokolsky
On Tue, Oct 12, 2010 at 4:22 PM, Radu Bogdan Rusu <[hidden email]> wrote:
Yeah, traditionally this is how ROS started:

136           uint8_t g = color.at<uint8_t>(u,v);
137           int32_t rgb = (g << 16) | (g << 8) | g;
138           points.channels[0].values.push_back(*(float*)(&rgb));

[code copied from stereo_image_proc]

:)

I agree with your assessment about uint32t. The problem was that for the first PointCloud.msg (which is not even supported in PCL), everything was a float, so things were just horrible.

I'm not sure what you mean with POINT4D. Are you referring to a message in ROS being called that way that could provide those values? I think there is no support for that in ROS. PCL is fine, but other pieces of code might make use of that too. However the overhead could be large (do you need a header for each point, etc?).


The PCL_ADD_POINT4D macro adds a union for a 4 float array that can also be accessed via x,y, and z.  If you defined a similar union, i.e.

union{
  float rgb_f;
  uint32_t rgb_u;
  struct {
    uint8_t r;
    uint8_t g;
    uint8_t b;
  }
}

it seems like that might make access a little easier.  I'm not sure how easily that works with Eigen and such though.

 

The standard way to handle colors in ROS right now is still the one that I mentioned above. This is one of the reasons why when you downsample something using pcl::VoxelGrid, the downsampled colors look bad. I guess we can add an _if_ in that loop and treat this as a special case...

Okay, I think I understand how it got there now, but from an outside user point of view it seems quite painful.

Cheers,
Mike


Cheers,
Radu.


On 10/12/2010 04:14 PM, Mike Sokolsky wrote:
I'm a little confused at the definition of PointXYZRGB - it declares a
float rgb field for the color data... I suppose you could pack the data
in and use a reinterpret_cast to read it out, but since the PointXYZRGBA
structure defines the field as a uint32 it seems like it could just be a
bug.

Also, would it make sens to provide a definition similar to POINT4D with
a union of the uint32 and four 8-bit types for x,y,z,a?  Or is there
already a standard way to handle colors in ROS?  Thanks.

Cheers,
Mike



_______________________________________________
[hidden email] / http://pcl.ros.org
https://code.ros.org/mailman/listinfo/pcl-users


_______________________________________________
[hidden email] / http://pcl.ros.org
https://code.ros.org/mailman/listinfo/pcl-users
Reply | Threaded
Open this post in threaded view
|

Re: PointXYZRGB

Mike Sokolsky
Also, it seems like the PCD format doesn't handle RGB color points, since it gets saved as an ASCII representation of the float value.  Or am I missing something?

I had come into this trying to use pcd_viewer to quickly take a look at some color point cloud data, perhaps I'm not going about this the best way, however.

Cheers,
Mike

On Thu, Oct 14, 2010 at 1:39 PM, Mike Sokolsky <[hidden email]> wrote:
On Tue, Oct 12, 2010 at 4:22 PM, Radu Bogdan Rusu <[hidden email]> wrote:
Yeah, traditionally this is how ROS started:

136           uint8_t g = color.at<uint8_t>(u,v);
137           int32_t rgb = (g << 16) | (g << 8) | g;
138           points.channels[0].values.push_back(*(float*)(&rgb));

[code copied from stereo_image_proc]

:)

I agree with your assessment about uint32t. The problem was that for the first PointCloud.msg (which is not even supported in PCL), everything was a float, so things were just horrible.

I'm not sure what you mean with POINT4D. Are you referring to a message in ROS being called that way that could provide those values? I think there is no support for that in ROS. PCL is fine, but other pieces of code might make use of that too. However the overhead could be large (do you need a header for each point, etc?).


The PCL_ADD_POINT4D macro adds a union for a 4 float array that can also be accessed via x,y, and z.  If you defined a similar union, i.e.

union{
  float rgb_f;
  uint32_t rgb_u;
  struct {
    uint8_t r;
    uint8_t g;
    uint8_t b;
  }
}

it seems like that might make access a little easier.  I'm not sure how easily that works with Eigen and such though.

 

The standard way to handle colors in ROS right now is still the one that I mentioned above. This is one of the reasons why when you downsample something using pcl::VoxelGrid, the downsampled colors look bad. I guess we can add an _if_ in that loop and treat this as a special case...

Okay, I think I understand how it got there now, but from an outside user point of view it seems quite painful.

Cheers,
Mike


Cheers,
Radu.


On 10/12/2010 04:14 PM, Mike Sokolsky wrote:
I'm a little confused at the definition of PointXYZRGB - it declares a
float rgb field for the color data... I suppose you could pack the data
in and use a reinterpret_cast to read it out, but since the PointXYZRGBA
structure defines the field as a uint32 it seems like it could just be a
bug.

Also, would it make sens to provide a definition similar to POINT4D with
a union of the uint32 and four 8-bit types for x,y,z,a?  Or is there
already a standard way to handle colors in ROS?  Thanks.

Cheers,
Mike



_______________________________________________
[hidden email] / http://pcl.ros.org
https://code.ros.org/mailman/listinfo/pcl-users



_______________________________________________
[hidden email] / http://pcl.ros.org
https://code.ros.org/mailman/listinfo/pcl-users
Reply | Threaded
Open this post in threaded view
|

Re: PointXYZRGB

Radu B. Rusu
Administrator
Mike,


On 10/14/2010 01:55 PM, Mike Sokolsky wrote:
> Also, it seems like the PCD format doesn't handle RGB color points,
> since it gets saved as an ASCII representation of the float value.  Or
> am I missing something?

The PCD format should be able to store the colors without any issue. The reason why the representation for the packed
RGB is still float is purely for compatibility reasons. If we look again at

136           uint8_t g = color.at <http://color.at><uint8_t>(u,v);
137           int32_t rgb = (g << 16) | (g << 8) | g;
138           points.channels[0].values.push_back(*(float*)(&rgb));


this is how the values are encoded in <PointCloud.msg> messages: by simply converting the packed 24bit RGB into a float.

> I had come into this trying to use pcd_viewer to quickly take a look at
> some color point cloud data, perhaps I'm not going about this the best
> way, however.


If you look into libpcl_visualization (pcl_visualization/src/libpcl_visualization/pcl_point_cloud_handlers.cpp), we do
the unpacking in a similar manner:

140     int rgb = *reinterpret_cast<int*>(&rgb_data);
141     scalar[0] = ((rgb >> 16) & 0xff);
142     scalar[1] = ((rgb >> 8) & 0xff);
143     scalar[2] = (rgb & 0xff);


This is not the way I would do it if we would design the system from scratch today, but for compatibility reasons and
visualization purposes it kind of does the job.

To get pcd_viewer to color your points using RGB data (where available), press "H" for help in the renderer window (this
will write the key shortcuts to the console), then "L" for listing the color and XYZ handlers available for your
dataset, and then simply press [0..9]/ALT+[0..9]/CTRL+[0..9]/etc for switching between them.


Suggestions for improving pcl_visualization are welcome! I was going to propose a more formal review process later,
after D-Turtle, as the core of PCL is more important to become stable than the visualizations for now.

Cheers,
Radu.
_______________________________________________
[hidden email] / http://pcl.ros.org
https://code.ros.org/mailman/listinfo/pcl-users
Reply | Threaded
Open this post in threaded view
|

Re: PointXYZRGB

Mike Sokolsky
Radu,

Thanks for the information about the viewer, that's exactly what I was looking for!

The issue with the float format I was referring to is limited to saved files, I don't think I explained it very well.  By default savePCDFile uses an ASCII format, which is where the problems arise.  There are a couple issues, the first is that there isn't a 1:1 mapping between integer values and floats and due to rounding and practical differences between libraries and hardware you won't always get the same value out as you put in anyway.  In memory it's 24 bits, and what's used to refer to them is irrelevant, but saving as an ASCII representation causes corruption.  The second issue, and I don't know exactly where it comes from, is in the current implementation any color value which maps to a un-normalized floating point value (which ends up being anything where the red channel has a value less than 0x80) is saved as a floating point value of '0' in the PCD file.

I'm currently using binary encoding to save things to get around the issue.

Cheers,
Mike

On Sun, Oct 17, 2010 at 3:16 PM, Radu Bogdan Rusu <[hidden email]> wrote:
Mike,



On 10/14/2010 01:55 PM, Mike Sokolsky wrote:
Also, it seems like the PCD format doesn't handle RGB color points,
since it gets saved as an ASCII representation of the float value.  Or
am I missing something?

The PCD format should be able to store the colors without any issue. The reason why the representation for the packed RGB is still float is purely for compatibility reasons. If we look again at

136           uint8_t g = color.at <http://color.at><uint8_t>(u,v);

137           int32_t rgb = (g << 16) | (g << 8) | g;
138           points.channels[0].values.push_back(*(float*)(&rgb));


this is how the values are encoded in <PointCloud.msg> messages: by simply converting the packed 24bit RGB into a float.


I had come into this trying to use pcd_viewer to quickly take a look at
some color point cloud data, perhaps I'm not going about this the best
way, however.


If you look into libpcl_visualization (pcl_visualization/src/libpcl_visualization/pcl_point_cloud_handlers.cpp), we do the unpacking in a similar manner:

140     int rgb = *reinterpret_cast<int*>(&rgb_data);
141     scalar[0] = ((rgb >> 16) & 0xff);
142     scalar[1] = ((rgb >> 8) & 0xff);
143     scalar[2] = (rgb & 0xff);


This is not the way I would do it if we would design the system from scratch today, but for compatibility reasons and visualization purposes it kind of does the job.

To get pcd_viewer to color your points using RGB data (where available), press "H" for help in the renderer window (this will write the key shortcuts to the console), then "L" for listing the color and XYZ handlers available for your dataset, and then simply press [0..9]/ALT+[0..9]/CTRL+[0..9]/etc for switching between them.


Suggestions for improving pcl_visualization are welcome! I was going to propose a more formal review process later, after D-Turtle, as the core of PCL is more important to become stable than the visualizations for now.

Cheers,
Radu.


_______________________________________________
[hidden email] / http://pcl.ros.org
https://code.ros.org/mailman/listinfo/pcl-users
Reply | Threaded
Open this post in threaded view
|

Re: PointXYZRGB

Radu B. Rusu
Administrator
Hi Mike,


On 10/18/2010 01:25 PM, Mike Sokolsky wrote:
> Radu,
>
> Thanks for the information about the viewer, that's exactly what I was
> looking for!

You're welcome.

> The issue with the float format I was referring to is limited to saved
> files, I don't think I explained it very well.  By default savePCDFile
> uses an ASCII format, which is where the problems arise.  There are a
> couple issues, the first is that there isn't a 1:1 mapping between
> integer values and floats and due to rounding and practical differences
> between libraries and hardware you won't always get the same value out
> as you put in anyway.  In memory it's 24 bits, and what's used to refer
> to them is irrelevant, but saving as an ASCII representation causes
> corruption.  The second issue, and I don't know exactly where it comes
> from, is in the current implementation any color value which maps to a
> un-normalized floating point value (which ends up being anything where
> the red channel has a value less than 0x80) is saved as a floating point
> value of '0' in the PCD file.

Hmm, interesting. I didn't think about that too much. Is there any way we could fix this in the save ASCII representation?

> I'm currently using binary encoding to save things to get around the issue.

Yeah, I was just about to suggest that. It would be nice however to fix the ASCII part too.

Cheers,
Radu.
_______________________________________________
[hidden email] / http://pcl.ros.org
https://code.ros.org/mailman/listinfo/pcl-users
Reply | Threaded
Open this post in threaded view
|

Re: PointXYZRGB

Mike Sokolsky


On Mon, Oct 18, 2010 at 3:40 PM, Radu Bogdan Rusu <[hidden email]> wrote:
Hi Mike,



On 10/18/2010 01:25 PM, Mike Sokolsky wrote:
Radu,

Thanks for the information about the viewer, that's exactly what I was
looking for!

You're welcome.


The issue with the float format I was referring to is limited to saved
files, I don't think I explained it very well.  By default savePCDFile
uses an ASCII format, which is where the problems arise.  There are a
couple issues, the first is that there isn't a 1:1 mapping between
integer values and floats and due to rounding and practical differences
between libraries and hardware you won't always get the same value out
as you put in anyway.  In memory it's 24 bits, and what's used to refer
to them is irrelevant, but saving as an ASCII representation causes
corruption.  The second issue, and I don't know exactly where it comes
from, is in the current implementation any color value which maps to a
un-normalized floating point value (which ends up being anything where
the red channel has a value less than 0x80) is saved as a floating point
value of '0' in the PCD file.

Hmm, interesting. I didn't think about that too much. Is there any way we could fix this in the save ASCII representation?

It gets pretty dicey to do this - it's incompatible across multiple machines with different floating point representations and subject to rounding errors from various implementations.
There are a couple things that could be done to make the situation much better in the current code, but honestly an ASCII floating point number doesn't clearly define a color in any generic way.  Would it be possible to special case the 'rgb' field to save/read as hex instead?  I think that's the only way to fully get around the issue.

I noticed looking through that it seems the PCD format is losing precision on floating point values in general when stored/read as ASCII, I'll do some more tests to confirm this and try and submit a fix.

Cheers,
Mike



I'm currently using binary encoding to save things to get around the issue.

Yeah, I was just about to suggest that. It would be nice however to fix the ASCII part too.

Cheers,
Radu.


_______________________________________________
[hidden email] / http://pcl.ros.org
https://code.ros.org/mailman/listinfo/pcl-users
Reply | Threaded
Open this post in threaded view
|

Re: PointXYZRGB

Radu B. Rusu
Administrator
Mike,

You're right. When you save the file as ASCII, you as a user specify the precision. I suppose we can make the default a
higher value (it's 5 right now). See:

50     int savePCDFileASCII (const std::string &file_name, const sensor_msgs::PointCloud2 &cloud, int precision = 5);
...
692     return (pcl::io::savePCDFileASCII (file_name, cloud, 5));
...
699   * \param precision the specified output numeric stream precision
700   */
701 int
702   pcl::io::savePCDFileASCII (const std::string &file_name, const sensor_msgs::PointCloud2 &cloud, int precision)


Cheers,
Radu.


On 10/20/2010 04:27 PM, Mike Sokolsky wrote:

>
> It gets pretty dicey to do this - it's incompatible across multiple
> machines with different floating point representations and subject to
> rounding errors from various implementations.
> There are a couple things that could be done to make the situation much
> better in the current code, but honestly an ASCII floating point number
> doesn't clearly define a color in any generic way.  Would it be possible
> to special case the 'rgb' field to save/read as hex instead?  I think
> that's the only way to fully get around the issue.
>
> I noticed looking through that it seems the PCD format is losing
> precision on floating point values in general when stored/read as ASCII,
> I'll do some more tests to confirm this and try and submit a fix.
>
> Cheers,
> Mike
>

_______________________________________________
[hidden email] / http://pcl.ros.org
https://code.ros.org/mailman/listinfo/pcl-users
Reply | Threaded
Open this post in threaded view
|

Re: PointXYZRGB

Mike Sokolsky
Doh, I guess I should spend a little more time looking through the code :)  Thanks!

Cheers,
Mike

On Wed, Oct 20, 2010 at 5:58 PM, Radu Bogdan Rusu <[hidden email]> wrote:
Mike,

You're right. When you save the file as ASCII, you as a user specify the precision. I suppose we can make the default a higher value (it's 5 right now). See:

50     int savePCDFileASCII (const std::string &file_name, const sensor_msgs::PointCloud2 &cloud, int precision = 5);
...
692     return (pcl::io::savePCDFileASCII (file_name, cloud, 5));
...
699   * \param precision the specified output numeric stream precision
700   */
701 int
702   pcl::io::savePCDFileASCII (const std::string &file_name, const sensor_msgs::PointCloud2 &cloud, int precision)


Cheers,
Radu.



On 10/20/2010 04:27 PM, Mike Sokolsky wrote:

It gets pretty dicey to do this - it's incompatible across multiple
machines with different floating point representations and subject to
rounding errors from various implementations.
There are a couple things that could be done to make the situation much
better in the current code, but honestly an ASCII floating point number
doesn't clearly define a color in any generic way.  Would it be possible
to special case the 'rgb' field to save/read as hex instead?  I think
that's the only way to fully get around the issue.

I noticed looking through that it seems the PCD format is losing
precision on floating point values in general when stored/read as ASCII,
I'll do some more tests to confirm this and try and submit a fix.

Cheers,
Mike




_______________________________________________
[hidden email] / http://pcl.ros.org
https://code.ros.org/mailman/listinfo/pcl-users
Reply | Threaded
Open this post in threaded view
|

Re: PointXYZRGB

Radu B. Rusu
Administrator
Or maybe we should spend more time documenting this on web pages :)

Cheers,
Radu.


On 10/20/2010 06:43 PM, Mike Sokolsky wrote:

> Doh, I guess I should spend a little more time looking through the code
> :)  Thanks!
>
> Cheers,
> Mike
>
> On Wed, Oct 20, 2010 at 5:58 PM, Radu Bogdan Rusu <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     Mike,
>
>     You're right. When you save the file as ASCII, you as a user specify
>     the precision. I suppose we can make the default a higher value
>     (it's 5 right now). See:
>
>     50     int savePCDFileASCII (const std::string &file_name, const
>     sensor_msgs::PointCloud2 &cloud, int precision = 5);
>     ...
>     692     return (pcl::io::savePCDFileASCII (file_name, cloud, 5));
>     ...
>     699   * \param precision the specified output numeric stream precision
>     700   */
>     701 int
>     702   pcl::io::savePCDFileASCII (const std::string &file_name, const
>     sensor_msgs::PointCloud2 &cloud, int precision)
>
>
>     Cheers,
>     Radu.
>
>
>
>     On 10/20/2010 04:27 PM, Mike Sokolsky wrote:
>
>
>         It gets pretty dicey to do this - it's incompatible across multiple
>         machines with different floating point representations and
>         subject to
>         rounding errors from various implementations.
>         There are a couple things that could be done to make the
>         situation much
>         better in the current code, but honestly an ASCII floating point
>         number
>         doesn't clearly define a color in any generic way.  Would it be
>         possible
>         to special case the 'rgb' field to save/read as hex instead?  I
>         think
>         that's the only way to fully get around the issue.
>
>         I noticed looking through that it seems the PCD format is losing
>         precision on floating point values in general when stored/read
>         as ASCII,
>         I'll do some more tests to confirm this and try and submit a fix.
>
>         Cheers,
>         Mike
>
>
>
_______________________________________________
[hidden email] / http://pcl.ros.org
https://code.ros.org/mailman/listinfo/pcl-users
Reply | Threaded
Open this post in threaded view
|

Re: PointXYZRGB

Radu B. Rusu
Administrator
In reply to this post by Mike Sokolsky
Btw, should we try to get RGB as 3 chars or as an uint32 or something before 1.0? The float cast is really ugly, and
there's really no reason for us to have that behavior anymore. It will drive some other changes in packages such as
stereo_image_proc and rviz for PointCloud2, but they are good changes ;)

Cheers,
Radu.


On 10/12/2010 04:14 PM, Mike Sokolsky wrote:

> I'm a little confused at the definition of PointXYZRGB - it declares a float rgb field for the color data... I suppose
> you could pack the data in and use a reinterpret_cast to read it out, but since the PointXYZRGBA structure defines the
> field as a uint32 it seems like it could just be a bug.
>
> Also, would it make sens to provide a definition similar to POINT4D with a union of the uint32 and four 8-bit types for
> x,y,z,a?  Or is there already a standard way to handle colors in ROS?  Thanks.
>
> Cheers,
> Mike
>
>
>
> _______________________________________________
> [hidden email] / http://pcl.ros.org
> https://code.ros.org/mailman/listinfo/pcl-users
_______________________________________________
[hidden email] / http://pcl.ros.org
https://code.ros.org/mailman/listinfo/pcl-users
Reply | Threaded
Open this post in threaded view
|

Re: PointXYZRGB

Dejan Pangercic
Hi there,

I am definitely in favor of this proposal.
It seem that rviz already supports it, this is copied from
http://www.ros.org/wiki/rviz/DisplayTypes/PointCloud:
"""
There are two ways to specify RGB:

3 channels, named "r", "g", and "b", with floating point values between 0 and 1.
1 channel, with the float in the channel reinterpreted as 3
single-byte values with ranges from 0 to 255. To send data this way
you have to reinterpret_cast the float as an int:
"""

D.
On Tue, Nov 16, 2010 at 5:28 PM, Radu Bogdan Rusu <[hidden email]> wrote:

> Btw, should we try to get RGB as 3 chars or as an uint32 or something before 1.0? The float cast is really ugly, and
> there's really no reason for us to have that behavior anymore. It will drive some other changes in packages such as
> stereo_image_proc and rviz for PointCloud2, but they are good changes ;)
>
> Cheers,
> Radu.
>
>
> On 10/12/2010 04:14 PM, Mike Sokolsky wrote:
>> I'm a little confused at the definition of PointXYZRGB - it declares a float rgb field for the color data... I suppose
>> you could pack the data in and use a reinterpret_cast to read it out, but since the PointXYZRGBA structure defines the
>> field as a uint32 it seems like it could just be a bug.
>>
>> Also, would it make sens to provide a definition similar to POINT4D with a union of the uint32 and four 8-bit types for
>> x,y,z,a?  Or is there already a standard way to handle colors in ROS?  Thanks.
>>
>> Cheers,
>> Mike
>>
>>
>>
>> _______________________________________________
>> [hidden email] / http://pcl.ros.org
>> https://code.ros.org/mailman/listinfo/pcl-users
> _______________________________________________
> [hidden email] / http://pcl.ros.org
> https://code.ros.org/mailman/listinfo/pcl-users
>



--
MSc. Dejan Pangercic
PhD Student/Researcher
Intelligent Autonomous Systems Group
Technische Universität München
Telephone: +49 (89) 289-26908
E-Mail: [hidden email]
WWW: http://ias.cs.tum.edu/people/pangercic
_______________________________________________
[hidden email] / http://pcl.ros.org
https://code.ros.org/mailman/listinfo/pcl-users
Reply | Threaded
Open this post in threaded view
|

Re: PointXYZRGB

Radu B. Rusu
Administrator
Sounds good, but we don't want floats anymore, so rviz still needs an update. In fact it might be more complicated to do
that if rviz already has the 3 channels, as we'll need to check the data type too, not just the name of the field. Rats.

Cheers,
Radu.


On 11/16/2010 08:41 AM, Dejan Pangercic wrote:

> Hi there,
>
> I am definitely in favor of this proposal.
> It seem that rviz already supports it, this is copied from
> http://www.ros.org/wiki/rviz/DisplayTypes/PointCloud:
> """
> There are two ways to specify RGB:
>
> 3 channels, named "r", "g", and "b", with floating point values between 0 and 1.
> 1 channel, with the float in the channel reinterpreted as 3
> single-byte values with ranges from 0 to 255. To send data this way
> you have to reinterpret_cast the float as an int:
> """
>
> D.
> On Tue, Nov 16, 2010 at 5:28 PM, Radu Bogdan Rusu<[hidden email]>  wrote:
>> Btw, should we try to get RGB as 3 chars or as an uint32 or something before 1.0? The float cast is really ugly, and
>> there's really no reason for us to have that behavior anymore. It will drive some other changes in packages such as
>> stereo_image_proc and rviz for PointCloud2, but they are good changes ;)
>>
>> Cheers,
>> Radu.
>>
>>
>> On 10/12/2010 04:14 PM, Mike Sokolsky wrote:
>>> I'm a little confused at the definition of PointXYZRGB - it declares a float rgb field for the color data... I suppose
>>> you could pack the data in and use a reinterpret_cast to read it out, but since the PointXYZRGBA structure defines the
>>> field as a uint32 it seems like it could just be a bug.
>>>
>>> Also, would it make sens to provide a definition similar to POINT4D with a union of the uint32 and four 8-bit types for
>>> x,y,z,a?  Or is there already a standard way to handle colors in ROS?  Thanks.
>>>
>>> Cheers,
>>> Mike
>>>
>>>
>>>
>>> _______________________________________________
>>> [hidden email] / http://pcl.ros.org
>>> https://code.ros.org/mailman/listinfo/pcl-users
>> _______________________________________________
>> [hidden email] / http://pcl.ros.org
>> https://code.ros.org/mailman/listinfo/pcl-users
>>
>
>
>
_______________________________________________
[hidden email] / http://pcl.ros.org
https://code.ros.org/mailman/listinfo/pcl-users
Reply | Threaded
Open this post in threaded view
|

Re: PointXYZRGB

lllegrand
One nice thing about having separate char fields for r, g, and b is that it opens the possibility of easily filtering on color.

> In fact it might be more complicated to do
> that if rviz already has the 3 channels,

We could always rename the char fields associated with the non-float color data (e.g. R,G,B instead of r,g,b)


_______________________________________________
[hidden email] / http://pcl.ros.org
https://code.ros.org/mailman/listinfo/pcl-users
Reply | Threaded
Open this post in threaded view
|

Re: PointXYZRGB

Radu B. Rusu
Administrator



On 11/18/2010 10:42 AM, Legrand, Louis L wrote:
> One nice thing about having separate char fields for r, g, and b is that it opens the possibility of easily filtering on color.

Ahhh - great point! Ok, let's put some effort into this then.

>
>> In fact it might be more complicated to do
>> that if rviz already has the 3 channels,
>
> We could always rename the char fields associated with the non-float color data (e.g. R,G,B instead of r,g,b)

I'm not a big fan of that as it might break things. Let's try to see if we can just change the PointCloud2 display in
RViz instead... I think everything else might just work. The only problem that I see here is 0-255 vs 0.0-1.0 .

Cheers,
Radu.
_______________________________________________
[hidden email] / http://pcl.ros.org
https://code.ros.org/mailman/listinfo/pcl-users