PDALio behavior with LAZ
Posted: Thu Sep 14, 2023 6:29 pm
CloudCompare 2.12.4 (Kyiv)
I have been using pylas/lazrs in python to create laz files from an AutoMap TerrusM LiDAR scanner. Everything seems to work ok when working just with LAS format files, but when working with LAZ format files there is one strange behavior: the Point Format is being read in as 129 when it should be 1, and 131 when it should be 3. When I attempt to save the file as LAS or LAZ format, PDAL throws an error of incorrect point format id.
When I dug into the pylas python script, I see they are setting the high bit of the eight bit point_format_id to "1" to indicate it is compressed data. I attempted to force this to not set the high bit to 1 for compression, CloudCompare refuses to load the LAZ files. When I dug into the various pieces to see where the misinterpretation of the point id to indicate the file is compressed, it seems to be in the LASFilter.cpp. If I try to modify this value anywhere in the processing chain before this, the file is unreadable. I hacked LASFilter.cpp to force point format to be a "correct" 1 or 3 if it is read as 129 or 131 respectively.
When I save the original files as LAS format, they are read in to CloudCompare correctly and can be saved as LAZ files.
The error seems to be specifically interpreting the LAZ point format id as having the high bit set to indicate it is a compressed file type.
I'm not sure if there is anyone who is capable of correcting this problem, either in a 2.12.4 update or in the 2.13 beta.
Thanks
I have been using pylas/lazrs in python to create laz files from an AutoMap TerrusM LiDAR scanner. Everything seems to work ok when working just with LAS format files, but when working with LAZ format files there is one strange behavior: the Point Format is being read in as 129 when it should be 1, and 131 when it should be 3. When I attempt to save the file as LAS or LAZ format, PDAL throws an error of incorrect point format id.
When I dug into the pylas python script, I see they are setting the high bit of the eight bit point_format_id to "1" to indicate it is compressed data. I attempted to force this to not set the high bit to 1 for compression, CloudCompare refuses to load the LAZ files. When I dug into the various pieces to see where the misinterpretation of the point id to indicate the file is compressed, it seems to be in the LASFilter.cpp. If I try to modify this value anywhere in the processing chain before this, the file is unreadable. I hacked LASFilter.cpp to force point format to be a "correct" 1 or 3 if it is read as 129 or 131 respectively.
When I save the original files as LAS format, they are read in to CloudCompare correctly and can be saved as LAZ files.
The error seems to be specifically interpreting the LAZ point format id as having the high bit set to indicate it is a compressed file type.
I'm not sure if there is anyone who is capable of correcting this problem, either in a 2.12.4 update or in the 2.13 beta.
Thanks