[Liblas-devel] LAZ / LAS extraction performance

[Michael Rosen]

Martin,

Good to hear from you.

I haven't scrutinized the compression difference between MG4 and LAZ and did not record encode times.

MG4 is a separate wavelete transform / arithmetic encoding on each channel (x, y, z, i, ...) except for GPS time.  GPS time is just Deflated (weaker compression scheme but works on floating point numbers).  Some LAS files don't store real values in GPS time.  I don't know if that's the case here but it's the first place I would look.  Here's a presentation that describes it ... more ( better?):  http://prezi.com/manlkjwyomj8/mg4-lidar-compression/ .

Does LASZip encode the integer coefficients or the calculated floating point values?  If the former, does it preserve most of the LAS structure but only replace the PDR payload?

Do you see a relationship between claimed resolution and the relative efficiency of the two compression schemes?

>A: Is it lossless in precision (i.e. are all bits of the internal integers x, y, and z faithfully reconstructed) ?
Yes.
>B: Is it lossless in all other properties (e.g. color, gps_time, scan angle, user data, ...)?
Yes.
>C: Is it lossless in the ordering
Yes.
>D: Is a lidar.las -> lidar.sid -> lidar_uncompressed.las conversion a bit-lossless operation?
No.  Sometimes some of the metadata (histogram values, Sys ID, custom VLR...) gets updated, dropped or garbled.

> las2las from LAStools or the las2las from liblas? 
las2las from OSGeo4W;  I have to think its the one from liblas.

warm regards,

msr
________________________________________
From: Martin Isenburg [martin.isenburg at gmail.com]
Sent: Friday, February 04, 2011 6:07 PM
To: Michael Rosen
Cc: liblas-devel at lists.osgeo.org
Subject: Re: [Liblas-devel] LAZ / LAS extraction performance

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 ... (-: