LAS 1.3 issues

[hobu]

@LAStools has identified a number of issues with the LAS driver in terms of LAS 1.3 support.

Hello,

after a little off-line discussion, here a summary about QT Modeller
and the LAZ format as well as some issues with LAS 1.3 files. The main
conclusion is that I recommend not to use the QT Modeller as a LiDAR
compressor or decompressor (e.g. to convert LAS files to LAZ files or
vice-versa) without triple-checking the results until they have
resolved the issues listed below. In general I advise to only use
laszip.exe for *purely* lossless compression and decompression since
it seems that most other software makes some changes when loading
LAS/LAS and writing LAS/LAZ to the contents, be it projection VLRs,
scaling factors, or just an overwriting of identifying strings such as
generating software, etc ...

In detail, QTM

* fails to load LAZ files with extra bytes

Under the hood QT Modeller seems to use PDAL whenever they are reading
or writing a LAZ file but use their own readers and writers for LAS
files. Because PDAL does not support "extra bytes" in LAZ (or LAS)
files it will crash if you open LAZ files containing "extra bytes".
This is trouble-some because "extra bytes" are exported to the LAZ
format, for example, by RIEGL's RiPROCESS to store attributes such as
echo width and normalized reflectance values.

* loads LAS files with extra bytes but omits them when writing to LAZ

It seems that the QTM loader can handle "extra bytes" with its native
LAS reader but it omits these "extra bytes" when using PDAL to export
those LAS files to LAZ.

* corrupts the global encoding bit when converting LAS files to LAZ

In case the bit was 1 in the LAS file it will be 0 in the LAZ file and
wrongly turn Adjusted Standard GPS time into GPS week time.

* corrupts loaded LAS 1.3 files when exporting them to LAS 1.2

It seems that the QTM writer does not properly handle the removal of
the 8 zero bytes that describe the "start of waveform data" when it
changes the version number from 1.3 down to 1.2 on export. Hence the
VLR  reading starts 8 zero bytes too early which makes them all
corrupt.

* changes the projection VLRs (but apparently still correct) when you
load LAS and save LAZ (amybe also LAS?).

Thanks to Ty for helping with tracking down these issues. Rest assured
that Mike Umansky from Applied Imagery is already on to fixing these
issues. He promised to have a fixed version out as soon as possible.

[rapidlasso]

In terms of LAS 1.3 that should be a pure QT modeler issue (assuming they
are not using PDAL to write LAS but only to write LAZ). The only issue I
saw for the PDAL-written (and read) LAZ files was the lack of extra-bytes
support and (maybe) some omitted or changed VLRs ...

On Thu, Apr 4, 2013 at 6:41 AM, Howard Butler notifications@github.comwrote:

@LAStools https://github.com/lastools has identified a number of issues
with the LAS driver in terms of LAS 1.3 support.

Hello,

after a little off-line discussion, here a summary about QT Modeller
and the LAZ format as well as some issues with LAS 1.3 files. The main
conclusion is that I recommend not to use the QT Modeller as a LiDAR
compressor or decompressor (e.g. to convert LAS files to LAZ files or
vice-versa) without triple-checking the results until they have
resolved the issues listed below. In general I advise to only use
laszip.exe for purely lossless compression and decompression since
it seems that most other software makes some changes when loading
LAS/LAS and writing LAS/LAZ to the contents, be it projection VLRs,
scaling factors, or just an overwriting of identifying strings such as
generating software, etc ...

In detail, QTM

• fails to load LAZ files with extra bytes

Under the hood QT Modeller seems to use PDAL whenever they are reading
or writing a LAZ file but use their own readers and writers for LAS
files. Because PDAL does not support "extra bytes" in LAZ (or LAS)
files it will crash if you open LAZ files containing "extra bytes".
This is trouble-some because "extra bytes" are exported to the LAZ
format, for example, by RIEGL's RiPROCESS to store attributes such as
echo width and normalized reflectance values.

• loads LAS files with extra bytes but omits them when writing to LAZ

It seems that the QTM loader can handle "extra bytes" with its native
LAS reader but it omits these "extra bytes" when using PDAL to export
those LAS files to LAZ.

• corrupts the global encoding bit when converting LAS files to LAZ

In case the bit was 1 in the LAS file it will be 0 in the LAZ file and
wrongly turn Adjusted Standard GPS time into GPS week time.

• corrupts loaded LAS 1.3 files when exporting them to LAS 1.2

It seems that the QTM writer does not properly handle the removal of
the 8 zero bytes that describe the "start of waveform data" when it
changes the version number from 1.3 down to 1.2 on export. Hence the
VLR reading starts 8 zero bytes too early which makes them all
corrupt.

• changes the projection VLRs (but apparently still correct) when you
  load LAS and save LAZ (amybe also LAS?).

Thanks to Ty for helping with tracking down these issues. Rest assured
that Mike Umansky from Applied Imagery is already on to fixing these
issues. He promised to have a fixed version out as soon as possible.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/122
.

[abellgithub]

We now have extra bytes support.