michael,<br><br>thanks a lot for such an insightful post. i was curious to see such numbers. any chance to also include a comparison of compression times?<br><br>let me comment on a few things, in particular about precision issues. some of the LAS files in you sets set have "funky" precision and that fact seems to coincide with those data sets where LAZ is not or barely beating SID.<br>
<br>* 2398_400 has an ueber-precision of 0.001 0.001 0.001. bit-lossless prediction coders (like LASzip) have a tough time compressing the scanner noise in the (most likely not-existing) millimeter accuracy that is preserved in this data set. <br>
<br>* Lincoln has an ueber-uber-ueber-precision of 1.45584e-006 1.38473e-006 6.72668e-008. a nightmare for bit-lossless prediction coders.<br><br>* Grass Lake Small has a "miss-precision" of 0.01 0.01 0.01 when in reality it should be 0.33 0.33 0.01 (see my lasprecision.exe post on the lidarbb for more info). the inflated difference between of the coordinates (they are all multiples of 33 instead of multiples of 1) cannot be compressed away by the current version of laszip. storing LAS files with more precision than they contain is a bad habit. does anyone how Grass Lake Small was created? could just be a sampled raster ...<br>
<br>It would be interesting to re-run the compression ratio comparisons after adjusting the precision of these files to the proper range (which can be done with lasprecision.exe) and see if this results in consistent changes.<br>
<br>That brings me to 4 questions that I have had since I first heard about the LT compressor that have to do with the lossless-ness of the compression: <br><br>A: Is it lossless in precision (i.e. are all bits of the internal integers x, y, and z faithfully reconstructed) ?<br>
B: Is it lossless in all other properties (e.g. color, gps_time, scan angle, user data, ...)?<br>C: Is it lossless in the ordering<br>D: Is a lidar.las -> lidar.sid -> lidar_uncompressed.las conversion a bit-lossless operation? <br>
<br>It is important to know these things so we know that we are comparing oranges with oranges.<br><br>Cheers,<br><br>Martin<br><br>PS: About the timings ... did you use the las2las from LAStools or the las2las from liblas? They implement the same compressor and clipping algorithm but the LAStools version is about 40% faster because it uses the lighter-weight, feature-poor LASlib API instead of Howard's celebrated, feature-rich, and award-winning liblas API ... (-:<br>