Question about scalar field defaulted as "grey"

[QuanticDisaster]

Hi

I would like to have a bit of information, when opening a point cloud, some scalar fields are automatically detected and assigned a specific behavior such as 'Coord.X', 'Red(0-255)' or 'Nx'. However, when I have intensity, it is often detected as 'Grey' and in this case, I do not know how to display the intensity scalar field. Moreover it is not saved when I save the point cloud afterwards forcing me to put it manually to 'Scalar field' when opening the file.

Could someone explain me what is the purpose and how should be used this 'grey' scalar field ?

Thx

[daniel]

Which version are you using? Because indeed, 'Grey' will just result in grey-level colors (so R=G=B=Intensity value). And it's not a scalar field.

But I'm surprised that CC suggests automatically to use this 'target'... I would be interested to see the file contents (at least the few first lines).

[QuanticDisaster]

The about section gives me version 2.11.3 (Anoia) on Windows 10 64 bit

You can make a try with these lines taken from the data if you wish (in .txt format)

//X Y Z R G B PointSourceId ScanAngleRank NumberOfReturns ReturnNumber GpsTime Intensity
-2234.844 254.918 1122.878 0 0 0 29.000000 25.271999 1.000000 1.000000 149852.579375 4096.000000
-2234.840 254.967 1122.881 0 0 0 29.000000 24.666000 1.000000 1.000000 149852.579573 4608.000000
-2234.841 254.998 1122.884 0 0 0 29.000000 24.257999 1.000000 1.000000 149852.579664 3840.000000
-2234.844 255.028 1122.885 0 0 0 29.000000 23.856001 1.000000 1.000000 149852.579756 4096.000000
-2234.855 255.060 1122.873 0 0 0 29.000000 23.243999 1.000000 1.000000 149852.579947 27904.000000
-2234.830 255.100 1122.898 0 0 0 29.000000 23.040001 1.000000 1.000000 149852.579993 23552.000000

CC indeed detects correctly coordinates and colors (which are 0 for most of the data, this is normal), but also intensity as 'Grey'. displaying rgb gives me the colors, and displaying scalar fields gives me the scalar fields except intensity

[daniel]

Ah that's weird, I'll probably have to fix that.

For now, you can manually change the last column role to 'Scalar Field' manually...

[QuanticDisaster]

Alright, I'll do. So grey and colors should be exclusive, that clears up my mind.

I am jumping on this occasion to ask if there is (and if there isn't, ask for it as a feature maybe ?) a way to save points clouds with the same precision given in input

if you use the following for instance

//X Y Z R G B PointSourceId ScanAngleRank NumberOfReturns ReturnNumber GpsTime Intensity
-2234.844 254.918 1122.878 0 0 0 29 25.271999 1 1 149852.579375 4096
-2234.840 254.967 1122.881 0 0 0 29 24.666000 1 1 149852.579573 4608
-2234.841 254.998 1122.884 0 0 0 29 24.257999 1 1 149852.579664 3840

You have a mix of scalar fields which are int, floats etc... you can even go further with scalar field having 6 elements after the decimal, and other having only 3.

However, when you save it (at least in ASCII format), you are only asked about the precision of coordinates and scalar fields, which makes the output like this :

//X Y Z R G B PointSourceId ScanAngleRank NumberOfReturns ReturnNumber GpsTime Intensity
-2234.844 254.918 1122.878 0 0 0 29.000000 25.271999 1.000000 1.000000 149852.578125 4096.000000
-2234.840 254.967 1122.881 0 0 0 29.000000 24.666000 1.000000 1.000000 149852.578125 4608.000000
-2234.841 254.998 1122.884 0 0 0 29.000000 24.257999 1.000000 1.000000 149852.578125 3840.000000

It would be great and save a lot of space on some point clouds to save only the necessary. I dont know if it is easy to do in C++, in python a trick could be to convert it to str, splitting up by "." and returning the len of the elements after but this may not be the best way

[daniel]

So first, I've updated the 2.12.beta version online so that it doesn't suggest to import 'Intensity' values as grey colors...

And next, regarding your question, the issue is that CC doesn't know if the scalar field is composed solely of integer values or not (as internally they are all represented as floating point values). Therefore, at export time, it exports all these values with the same 'precision'.

We could try to determine dynamically if a scalar field is composed solely of integer values, but it will make the export procedure even slower (but on the other side, since it's already super slow when exporting to ASCII, it may not make such a big difference).

By the way, if you are concerned about the size, shouldn't you export to another binary format? Such as LAS or PLY?

[QuanticDisaster]

Just checked, the problem is corrected on 2.12.beta version

This is why I was thinking about reading the precision at the moment of reading the point instead of looking at interal float values

But I am puzzled, I just tried to save it in .ply format with ASCII and it works and saves the correct precision, how come ?

end_header
-2234.84 254.918 1122.88 0 0 0 29 25.272 1 1 149853 4096
-2234.84 254.967 1122.88 0 0 0 29 24.666 1 1 149853 4608
-2234.84 254.998 1122.88 0 0 0 29 24.258 1 1 149853 3840
-2234.84 255.028 1122.89 0 0 0 29 23.856 1 1 149853 4096
-2234.85 255.06 1122.87 0 0 0 29 23.244 1 1 149853 27904

Indeed LAS and PLY format are more suited, however I was just lazy in using an additionnal library/create a function to read ply files in my python script next, while pandas could read directly as a txt, but I will look into it.

[daniel]

Ajh, probably the rPLY library is smarter than our ASCII filter ;)