[2.14.beta] Saving to LAS/LAZ zeroes the scale of scaled extra-bytes fields

[jlin]

Hi,

In CloudCompare v2.14.beta (2026OCT24 build, Windows 10 64-bit), saving a cloud to LAS or LAZ destroys any extra-bytes field that has a scale factor. The field is still in the saved file, but when the file is reopened every point reads 0.

What happens

• Loading is fine: an int16 extra-bytes field with scale 0.0001 shows the correct values (-0.499 to +0.500 in my test file).
• On save, the extra-bytes descriptor keeps the "scale" option bit but the scale is written as 0.0. If the input declared a no-data value, that bit is dropped too.
• The stored integers become 32767 for every positive value, -32768 for every negative value and 0 for exact zeros, so only the sign survives. It looks as if each value is divided by the zero scale and clamped to the int16 range.
• Reopening the saved file in CloudCompare shows the field as 0 on every point.

Steps to reproduce

1. Use the attached file. It is a 32 x 32 grid with one int16 extra-bytes field "displacement", scale 0.0001, ramping from -0.5 to +0.5.
2. Run:

   Code: Select all

   CloudCompare -SILENT -AUTO_SAVE OFF -NO_TIMESTAMP -O scaled_int16.laz -C_EXPORT_FMT LAS -EXT laz -SAVE_CLOUDS FILE scaled_int16.cc_saved.laz

3. Open scaled_int16.cc_saved.laz: "displacement" is 0 everywhere.

The same happens with -EXT las, whether or not the cloud is cropped first, and when saving from the GUI. I first hit it by segmenting a cloud and saving the selection as LAZ.

Extra-bytes descriptor before and after the save, read with laspy:

Code: Select all

input  scaled_int16.laz           data_type 4 (int16)  options 0b11000  scale 0.0001  offset 0.0   raw values -4990 ... 5000
saved  scaled_int16.cc_saved.laz  data_type 4 (int16)  options 0b11000  scale 0.0     offset 0.0   raw values only -32768, 0, 32767

Field types I tested

• int16, scale 0.0001: broken
• int16, scale 0.0001, no_data -32768: broken (no_data bit also dropped)
• int32, scale 0.0001, no_data: broken
• int16, no scale: OK, raw values identical
• float32, no scale: OK, values identical
• Same scaled int16 cloud exported to PLY instead: OK

I can send the input and saved files, or test a newer build.

Thanks

[daniel]

Thanks for the report. We will investigate (you could even open a github issue if you want to follow this more closely).

[daniel]

This should be fixed now in the latest 2.14.beta version!