R crashes when trying to use the rlas lidr command readLAS with some .las files

[beyakk]

Fully updated versions of R, rlas, lidr (version 4.1.1). I am working with las files created in Agisoft Metashape with no problem.

If I try to load the same dataset created in LASTools or Whiteboxtools (opencore for both) R crashes consistently. These files open and I have no issues in other software (i.e. QGIS).

Tried in RStudio as well as regular R Terminal, tried with the files formatted as both las and laz files. Since it sounds like CRS informaiton can be a cause of something like this I viewed the las files headers and compared CRS information. It appears identical line-for-line in the files that work and those that do not, additionally readLAScatalog() when applied to the files will report the correct CRS. However I cannot work with the files without readLAS. test.zip

I have created very small subset files that show the issue- clip20m.las was created in Agisoft Metashape and lidR and loads just fine. crash-clip20m.las was created in AgisoftMetashape and LASTools lasclip, it cannot be read into lidR with readlas() as it causes an immediate crash of R or RStudio.

QGIS will read both files just fine including the CRS information. Would prefer to be able to use multiple sets of tools (WBT, LASTools, lidR, etc.), also concerned if there is some problem with the files although they appear to validate as correct to ASPRS format with lasvalidate. Currently my primary reason to switch between software packages is the ability to fully remove degenerated ground points with the same xy coordinates which it seems there is not a straightforward method for in lidR (duplicates only removes those with the same xy&z).

I don't get any error messages as R promptly crashes with the gray bomb and closes. Is this user error or a bug? Either way any ideas of how to solve it? Still pretty new to working with lidar files and jumping back into using R after many years, any help is much appreciated!

[Jean-Romain]

Reproduced. It comes from the extrabytes

rlas::read.las("~/Téléchargements/test/crash-clip20m.las")
==64656== Invalid read of size 1
==64656==    at 0xE1E6830: RLASExtrabyteAttributes::get_attribute_double(LASpoint*) (rlasextrabytesattributes.cpp:52)
==64656==    by 0xE1E7624: RLASExtrabyteAttributes::push_back(LASpoint*) (rlasextrabytesattributes.cpp:29)
==64656==    by 0xE1DCD04: RLASstreamer::write_point() (rlasstreamer.cpp:558)
==64656==    by 0xE1E863F: C_reader(Rcpp::Vector<16, Rcpp::PreserveStorage>, Rcpp::Vector<16, Rcpp::PreserveStorage>, Rcpp::Vector<16, Rcpp::PreserveStorage>, Rcpp::Vector<16, Rcpp::PreserveStorage>, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >) (readLAS.cpp:58)
==64656==    by 0xE207261: _rlas_C_reader (RcppExports.cpp:116)
==64656==    by 0x495A29D: ??? (in /usr/lib/R/lib/libR.so)
==64656==    by 0x499D687: ??? (in /usr/lib/R/lib/libR.so)
==64656==    by 0x49B119C: ??? (in /usr/lib/R/lib/libR.so)
==64656==    by 0x49B150A: Rf_eval (in /usr/lib/R/lib/libR.so)
==64656==    by 0x49B36DE: ??? (in /usr/lib/R/lib/libR.so)
==64656==    by 0x49B44C6: ??? (in /usr/lib/R/lib/libR.so)
==64656==    by 0x49B163B: Rf_eval (in /usr/lib/R/lib/libR.so)
==64656==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==64656== 

 *** caught segfault ***
address (nil), cause 'memory not mapped'

[Jean-Romain]

The problem is in LASlib. Try it with LASools: it crashes

las2txt crash-clip20m.las -parse xyz0 -otxt 

This should be reported in LAStools https://github.com/LAStools/LAStools. I don't know if the file is corrupted or not. It is impossible to read the extra bytes. You can read the file without the extrabytes

rlas::read.las("~/Téléchargements/test/crash-clip20m.las", select = "xyz")

I think it the same bug than https://github.com/r-lidar/rlas/issues/59 and I will probably not fix it. You are saying that QGIS reads it properly but does QGIS loads extrabytes?

[beyakk]

Much appreciated, this is very helpful. Based on the information I did figure a kind of ugly work around by loading the file into R with only the xyz points (ie. las <- readLAS("crash-clip20m.las", select = "xyz")) and then writing to a new file and proceeding to work with that file.< I also discovered that the files I created with LASTools and WBT that had this issue loading in R/lidR also will not load back into Agisoft Metashape even though they report as valid ASPRS format files according to LASTools validate tool. I have decided to change my workflow to do all manipulation in R/lidR for the time being. Reading a bit more it seems like this might be a bit of a known issue with the las format overall and the reason for the creation of las 1.4 which it sounds like was done in large part to standardize how extrabytes are written into the las format due to compatability issues between software packages. I am guessing maybe I have run afoul of this issue? I discovered that my files are las 1.2.

If it is of interest, I did try converting a file to las 1.4 using LASTools las2las tool- the result would open in Agisoft but not in QGIS and not in R/lidR possibly any issues with 1.2 just persist through? I will try exporting my original file as las 1.4 and beginning with that one, possibly that will sidestep the issue- sounds like that is where my files should be anyways.

I will report this at LASTools as suggested. Very much appreciate the advice and expertise!

[Jean-Romain]

Notice that in las2txt it works if you do not read the extrabytes

las2txt crash-clip20m.las -parse xyz -otxt

For the other questions, I'm sorry, in absence of reproducible examples and reproducible files I can't say anything.

[Jean-Romain]

Please delete your lastools bug report and create a dedicated one for lastools that do not mention rlas and lidR but that is reproducible with lastools. You illiterately copied the bug report here into LAStools. Lastools is not a place to report issues with lidR. You did not even mention a way to reproduce the bug. I can do the bug report if you prefer.

[beyakk]

My apologies, I am new to this and just getting a grasp on the various dependencies I did not realize lidR was also running on the LASlib. I've run the issue down a bit farther and it appears that the problem happens when files are created by whiteboxtools (the crash-clip file I provided was a clip from a las file created by whiteboxtools. I am confused about how LASTools can work with the file but lidR cannot since they are both using LASlib.

It looks like I cannot delete my post but I will edit/update the issue.

[Jean-Romain]

As shown above lastools does not work. As long as it does not try to read the extrabyte values it works. But if you try to read the extrabyte it crashes.