Using laszip_add_vlr() in laszip.dll produces VLR headers with the reserved value set to 0xAABB for V1.4 LAS files

[mc...@u.washington.edu]

Working on updates to FUSION to write V1.4 LAS files and I ran across an issue with the laszip_add_vlr() function in the LASzip DLL. If you call the function to add a new VLR to a file, the "Reserved" field is hard-coded to 0xAABB (line 1321 in laszip_dll.cpp). This was correct for LAS version 1.0 and unclear in V1.2 & 1.3 but V1.4 requires this field to be 0.

It would also seem that there is a validity test in laszip_dll.cpp that check the "Reserved" field using the 0xAABB (line 3280).

The VLR for compression also uses the 0xAABB value.

I didn't look at any other code in LAStools to see if this problem is elsewhere but did notice that the example V1.4 LAS file that is included in the LASzip dll distribution (5points_14.las) also uses the 0xAABB value in the WKT VLR.

Just wondering if anyone else has seen this and if a fix is needed...

Bob

==========================================================
Bob McGaughey USDA Forest Service
(206) 543-4713 University of Washington
FAX (206) 685-0790 Bloedel 386
PO Box 352100
bmcga...@fs.fed.us Seattle, WA 98195-2100
==========================================================

[Martin Isenburg]

Hello Bob,

Nice catch. I will have to change that. It's already done in LASlib but I forgot to make that change also in the DLL code.

I have copied the "LAS room" because I cannot recall why this change was made. Anyone remember? Why did we change the "reserved" field of the VLR from the value 0xAABB to zero in the LAS 1.4 specification? Was there a good reason to do so? In my open source code I had the value 0xAABB because that is what it was in the initial LAS specifications that I had based it on. Why was it the value 0xAABB to start with?

Unfortunately the entire history of the ASPRS LAS Working Group (LWG) - as I have lamented previously - was in parts carelessly lost and in parts deliberately erased and despite my repeated calls to do proper record keeping, continues to be undocumented and continues to go on without any of the protocols usually employed by standardisation bodies ... /-:

Back to the question. Should we just make zero the new default for all VLRs? Is there any software that requires the reserved field to be 0xAABB for older LAS versions? Which ones? Only LAS 1.0?

Regards from Thailand,

Martin @rapidlasso

[Evon Silvia]

​I'll chime in to say that I'm not aware of any software that looks for the 0xAABB flag when seeking a VLR, as it was only present in the oldest version of LAS. I believe it's now expected to be 0x0000, but I can't find anything in the specification that explicitly requires this until 1.4.

It's not uncommon for files circa early 2000s to have a "token" at the start of each data block, and the LAS 1.0 specification had the same thing:

• "LASF" - start of LAS file
• 0xAABB - start of each LAS VLR (deprecated to Reserved in 1.1, explicitly required to be 0x0000 in 1.4)
• 0xCCDD - start of point data follows (removed in 1.1)

I wasn't on the committee for the initial design of the specification, but I'm going to guess that these tokens were intended to provide a way to "recognize​" the start of a VLR if for some reason the file header became invalid, or while streaming data and the header offset was initially unknown, or if one ever decided to store the header, VLR(s), and points in separate files temporarily. Unfortunately, there's no guarantee that these sequences will be absent from the contents of each data block, so I imagine it was deemed unreliable and therefore deprecated later.

It's a shame, really, for exactly the reasons for the existence of those post... either keep or always or remove it before the initial design. I've failed thousands of LAS 1.2+ files that still have the 0xCCDD tag even though it was deprecated a decade ago.

Evon

--

Evon Silvia PLS Solutions Developer 517 SW 2nd Street, Suite 400, Corvallis, OR 97333 P: (541) 452-8502 E: esi...@quantumspatial.com

--
--
You are subscribed to "The LAS room - a friendly place to discuss the the LAS or LAZ formats" for those who want to see LAS or LAZ succeed as open standards. Go on record with bug reports, suggestions, and concerns about current and proposed specifications.
 
Visit this group at http://groups.google.com/group/lasroom
Post to this group with an email to las...@googlegroups.com
Unsubscribe by email to lasroom+unsubscribe@googlegroups.com
---
You received this message because you are subscribed to the Google Groups "The LAS room - a friendly place to discuss the LAS and LAZ formats" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lasroom+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Evon Silvia]

...but to answer Martin's question: Yes, default to zero. If the user writes out a LAS 1.0 file, then override with 0xAABB.

Evon

[Martin Isenburg]

Hello,

this has been changed in the latest DLL. Note that the files "laszip_dll.h" and  "laszip_dll.c" were renamed to  "laszip_api.h" and  "laszip_api.c" as - thanks to Howard Butler (aka hobu) the same source code can now be used as a shared library under UNIX/LINUX unless I have broken something ... (-:

These are all the small fixes in the DLL (see CHANGES.txt in the LAStools\LASzip folder):

8 January 2017 -- changed file names from "laszip_dll.h" to "laszip_api.h" for hobu

7 January 2017 -- set reserved field in LASzip VLR from 0xAABB to 0x0

7 January 2017 -- make scan angle quantization in compatibility mode consistent with LASlib

7 January 2017 -- compatibility mode *decompression* fix for points with waveforms

Cheers,

Martin @rapidlasso

--
Download LAStools at
http://lastools.org
http://rapidlasso.com
Be social with LAStools at
http://facebook.com/LAStools
http://twitter.com/LAStools
http://linkedin.com/groups/LAStools-4408378
Manage your settings at
http://groups.google.com/group/lastools/subscribe