[Liblas-devel] LAZ / LAS extraction performance

Martin Isenburg martin.isenburg at gmail.com
Fri Feb 4 21:07:43 EST 2011


michael,

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?

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.

* 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.

* Lincoln has an ueber-uber-ueber-precision of 1.45584e-006 1.38473e-006
6.72668e-008. a nightmare for bit-lossless prediction coders.

* 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 ...

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.

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:

A: Is it lossless in precision (i.e. are all bits of the internal integers
x, y, and z faithfully reconstructed) ?
B: Is it lossless in all other properties (e.g. color, gps_time, scan angle,
user data, ...)?
C: Is it lossless in the ordering
D: Is a lidar.las -> lidar.sid -> lidar_uncompressed.las conversion a
bit-lossless operation?

It is important to know these things so we know that we are comparing
oranges with oranges.

Cheers,

Martin

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 ... (-:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/liblas-devel/attachments/20110204/3294b12f/attachment.html


More information about the Liblas-devel mailing list