Changed the Glasbey Color Lookup, such that label ids get consistent colors.

[mschoeler]

This is especially important, if labels have a semantic meaning (classes) (say 1=chair, 2=door, 3=floor, 4=wall ).
If a chair is missing in a pointcloud (label 1 is absent) than the colors of all objects would change.
Additionally, it is much faster, since we do not iterate through clouds multiple times as well as saving time on various map lookups.

[jpapon]

I think this is a very nice change, since it eliminates lots of unnecessary overhead (since label colors are modulo GlasbeyLUT::size () anyways), especially on large point clouds.

The degenerate case is if the only labels present just happen to be exact multiples of GlasbeyLUT::size (), but that seems unlikely.

[mschoeler]

Just saw that the glasbey colormapping is used in other files like
pcl/io/include/pcl/io/impl/point_cloud_image_extractors.hpp.
This I would make consistent.
@taketwo Since you implemented the glasbey colors: What is your oppinion on this pull request?
Cheers,
Markus

[taketwo]

I get your point regarding consistent mapping between labels and colors and agree that it is useful. On the other hand, the idea of using Glasbey table is to select optimal (most distinctive) set of colors of given size. If you only have three labels and select first three colors from the table, then they as distinctive as possible. But if you select some (according to labels) three colors from the table, there are no guarantees. (Or, strictly speaking, there is a guarantee that distinctiveness will not be worse than between optimal 256 colors.)

What about providing an option at construction time? By default the users will get most distinctive colors. As an opt-in, they can have static color assignment.

[mschoeler]

I think your proposal with providing an option at construction time
would work. For the pcd_viewer I would rather propose the static mapping
to be the default, since I think it is more common to have a label
disappear in pointclouds or labels having semantic meaning than
situations were label ids are so far apart, that the non optimal colors
would cause any problem. So I would propose a command line switch to
have the optimal colors selected. Additionally, the default would here
have a smaller overhead which would make the initialization quicker.

[taketwo]

Fine for me.

I would suggest a bool argument, something like bool static_mapping = true in PointCloudColorHandlerLabelField constructor.

After we merge your pull request, I'll take care of point cloud image extractor myself, because it will also require to change the pcd2png command-line tool.

[mschoeler]

sounds good

[mschoeler]

here we go. @taketwo I hope I got all the dependencies. But my tests worked all fine.

[taketwo]

I thought we'd make static_mapping = true by default so that the users that programatically create a visualizer and add label point cloud get the same result as if they opened this cloud in pcd_viewer?

[mschoeler]

Mmh, from your comment

By default the users will get most distinctive colors. As an opt-in, they can have static color assignment.

I thought you want to have the optimal assignment as default. But I would totally agree that due to the additional overhead (and also hard to predict color-assignments) of the optimal mapping I would make static_mapping = true default for the visualizer as well as the pcd_viewer.

[taketwo]

I thought you want to have the optimal assignment as default.

Yep, that was my idea in the beginning. But then after your comment

I think it is more common to have a label disappear in pointclouds or labels having semantic meaning than situations were label ids are so far apart, that the non optimal colors would cause any problem.

I reconsidered. So my "Fine for me" was referring to making static default everywhere.

[mschoeler]

ok, got that. Here are the changes 😄