[Done] Improving "color space" with a random color ramp

[tochaf]

I'm not sure whether this solution already exists, but here it goes

I’m working with small-footprint high-resolution (+/- 10pt?m2) airborne LiDAR point clouds over tropical forests.

I generated point clouds for which the attribute “classification” corresponds to a label that is assigned to each individual tree. Meaning that LIDAR single points are gathered together if they belong to the same individual. Such points will have a unique classification ID, i.e. a label.

For instance, if I have 3500 trees in my dataset I will have 3500 labels. Most so often, adjacent trees have labels very close (e.g. 34, 35 and 36). Using the current scalar fields, the colors will be spanned from 1 to 3500 and we cannot visually distinguish between tress #34, #35 and #36: they are displayed with similar colors.


I was wondering if you could not introduce a “random color ramp” or any other solution that you better than me can figure out to improve the visualization of the classification of individual objects in forests or urban areas.

The idea is that to labels #34, #35 and #36 could be assigned a random color so that we can distinguish between close objects with close labels.

Thank you

[daniel]

Hum, the color ramp mechanism is clearly not meant to represent such a big number of different colors... Would random RGB colors work?

[jedfrechette]

Another option that might work is to simply cycle through colors from a predefined color map containing a relatively small number of colors. For example, one of the Color Brewer palettes designed for categorical data. The advantage of using one of these colormaps is that they are specifically designed to provide good contrast, something that can be hard to assure if you are using completely random colors. Reusing colors is OK because there will still be good contrast locally and it doesn't matter that tree # 34 has the same color as tree number # 89, which is 100 m away. Even if you did use 3500 distinct colors no human is going to be able to visually distinguish all of those shades anyway.

I can't speak for the specific application here, but I've had pretty good success using this strategy in similar situations.

[Dimitri]

Daniel, weren't you using random color attribution for the connected component color attribution ? This was working quite well in our case when we separated hundreds of vegetation bushes. So I suppose that a random color ramp could work based on a color increment every integer value of the scalar field.

[daniel]

Indeed, but it's random RGB colors (one per cloud). It's not the same as a SF color map. This is why I suggested random RGB colors instead.

[tochaf]

Hi

I think that the color ramps currently available in CloudCompare are adapted to do this job.
0
Of course, there will be some clusters (trees in my case) that will display nearly the same color: let's say (RGB)=(0.4,0.1,0.9)).

However, because the color would be randomly assigned to every cluster, clusters displaying a similar color will be many meters apart so that we can easily figure out that they are not the same cluster.

[tochaf]

I' sorry .... but the last comment was for RGB colors, which would be the ideal case.

but, I was willing to say that the color ramps currently available in CloudCompare could work as well.

Currently, I'm using ClodCompare to display my forest trees LiDAR point clouds.

For each cluster corresponding to a tree, I generate an additional attribute called "color" and I randomly generate a value for such attribute in the range [0,256].

Then, I use the color ramps available in CloudCompare and we can visually distinguish between adjacent trees. Of course, in some cases my strategy generates adjacent trees with a very close color and we can not distinguish them. That's why the RGB sapce would be much better becasue it reduces the probability of two or more trees with the same color.

[daniel]

I might not have been very clear but the issue here is the number of values. A color scale in CC can't handle so many different values (in fact pairs of scalar value and color).

For me there's only two reasonable possibilities:

• either to use a "random RGB color generator" based on the SF values (simpler)
• or to use a cycling color scale as Jed suggested (this one might have more impact on the code as it sounds)

[tochaf]

Ok, I understand , I think the "random RGB color generator' should be good enough for most individual-objets segmentation applications.

Do you think that this would be a significant improvement to CC and are you thinking in implement such functionality ?

best


Antonio

[daniel]

Ok a new method is now available: "Edit > Scalar field(s) > Convert to random RGB".

You'll just have to specify the number of random colors to generate and CC will apply them by sampling them regularly on the active scalar field.

Will be available in the next release (this week-end hopefully).