Issue Reading GUIDs in lasinfo

[Casey Johnston]

Hello,

I'm encountering a persistent discrepancy in how the GUID (Project ID) in LAS file headers is read and written between LAStools (lasinfo) and other software tools such as Laspy, PDAL, LP360, and QGIS.

When reading the GUID from the LAS file header using Laspy, PDAL, LP360, and QGIS, all these tools report the same GUID value.

However, when using lasinfo from LAStools, it reports a different GUID for the same LAS file.

Setting the GUID using lasinfo with the -set_guid option results in only lasinfo recognizing the correct GUID afterward.

Other software tools then read an incorrect GUID from the LAS file.

Conversely, setting the GUID using the other tools leads to them reading the correct GUID, while lasinfo reports it incorrectly.

The GUIDs appear to be byte-swapped versions of each other, suggesting an endianness issue or misinterpretation in how the GUID is read or written.

This issue persists across recent datasets and data produced since 2017.

lasinfo seems to be the only tool among those tested that reports the GUID differently.

The discrepancy causes confusion and potential metadata misalignment when sharing LAS files between different workflows and publications.

Could you please investigate this discrepancy in GUID interpretation in lasinfo? It appears there may be an issue with how lasinfo handles the GUID's byte order or format compared to other software tools.

Any guidance or fix you could provide would be greatly appreciated, as it would help ensure consistent metadata across our lidar deliverables.

LAStools may be handling it correctly and it is the other software tools that are wrong, or maybe the problem is between the chair and the keyboard - I do not know.

Attached is a text file with an example GUID and code used to test it. Please let me know if you need anything else.

Thank you for your assistance,

Casey Johnston, CP, GISP
Senior Systems Specialist | JALBTCX

[Jochen Rapidlasso]

Hi Casey,

thanks for the description of the problem. We will fix this issue in lasinfo/lasinfo64.

FYI: laslook displays the GUID in the same way than QGIS/the other tools does.

Best regards,

Jochen @rapidlasso

[Rainer Wiesenfarth]

Hi,

yes, lasinfo is wrong.

The standard tells: ulong, ushort, ushort, char[8], Intel byte order (i.e. little endian).

That means for a file like below (see hexdump) the GUID should be 00112233-4455-6677-8899-AABBCCDDEEFF.

However, lasinfo returns:

  project ID GUID data 1-4:   00112233-4455-6677-9988-BBAAFFEEDDCC

The eight chars are handled (or printed) in wrong order.

Cheers, Rainer

--
Download LAStools at
https://rapidlasso.de
Manage your settings at
https://groups.google.com/g/lastools/membership
---
You received this message because you are subscribed to the Google Groups "LAStools - efficient tools for LiDAR processing" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lastools+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/lastools/5769c54a-9099-4304-9b84-efa4db18038fn%40googlegroups.com.

--

Rainer Wiesenfarth Senior Software Engineer Geospatial Division Rotebühlstr. 81, 70178 Stuttgart Germany Rainer_Wi...@trimble.com geospatial.trimble.com/products-and-solutions/trimble-inpho Trimble Services GmbH, Am Prime Parc 11, 65479 Raunheim, Eingetragen beim Amtsgericht Darmstadt unter HRB 83893, Geschäftsführer: Rob Reeder, Jürgen Kesper

[Casey Johnston]

Hi Jochen & Rainer,

Thank you for looking into this and fixing the issue.

Regards,

Casey

[Jochen Rapidlasso]

This issues is fixed now for lasinfo64 with the current version (241125).

     

Cheers,

Jochen @rapidlasso