read PLY files?

[dschneiderch]

As far as I can tell there is no way to read ply files. do you have any plans to support this? Currently I can convert my binary ply files to las using PDAL but that is less then ideal.

Thanks

[Jean-Romain]

No plan, and actually I don't know this format and I've never encountered such file. I have only read the Wikipedia page that states this is a format related to mesh storage. I don't see how it can be related to point clouds.

That being said, LASlib has a class LASreaderPLY. So we should be able to read ply files with the rlas package. If you tell me why it is useful and you give me ply files it might be a feature for rlas.

[Jean-Romain]

I pushed a commit to unlock reading of ply files as point cloud.

library(rlas)
library(lidR)
pts    <- read.las("~/Téléchargements/Sunduk_complete.ply", select = "xyz")
header <- read.lasheader("~/Téléchargements/Sunduk_complete.ply")
las    <- LAS(pts, header)
plot(las, colorPalette = "white")

I also removed the hard coded limitation to .las and .laz in readLAS from lidR. You will be able to read .ply file as las files. With lidR 2.0.3 and rlas 1.3.3 this works:

library(lidR)
las <- readLAS("~/Téléchargements/Sunduk_complete.ply", select = "xyz")
plot(las, colorPalette = "white")

But this will remain an undocumented feature.

[dschneiderch]

Thank you so much for considering the issue! This works great with my ply files.

I'm fairly new to 3d point cloud data but .ply is the format that I get from our instrument even though most people are using las. I don't know the dis/advantages of either format. I suspect the vendor who integrates the 3d scanner in my lab is using opencv for image processing and viz:::readCloud only supports ply, xyz, stl, obj

is there a particular reason you wish to keep it undocumented? let me know if you still want a sample ply file.

> lidlas = readLAS(fn)
parsed: format binary_little_endian 1.0
parsed: comment created by Fraunhofer IIS
parsed: element vertex 1292930
parsed: property float x
parsed: property float y
parsed: property float z
parsed: property uchar gray
not supported: element face 0
skipping remaining header ...
parsed: format binary_little_endian 1.0
parsed: comment created by Fraunhofer IIS
parsed: element vertex 1292930
parsed: property float x
parsed: property float y
parsed: property float z
parsed: property uchar gray
not supported: element face 0
skipping remaining header ...
Warning messages:
1: Invalid file: some points are outside the bounding box defined by the header 
2: Invalid file: some points are outside the elevation range defined by the header 
3: Invalid file: the header states the file contains 0 returns numbered '1' but 1292930 were found. 
> lidlas
class        : LAS (LASF v1.2)
point format : 0
memory       : 88.8 Mb 
extent       :-63.319, 94.713, 144.126, 361.404 (xmin, xmax, ymin, ymax)
coord. ref.  : NA 
area         : 33536.35 units² (convex hull)
points       : 1292930 points
density      : 38.55 points/units²
names        : X Y Z Intensity ReturnNumber NumberOfReturns ScanDirectionFlag EdgeOfFlightline Classification Synthetic_flag Keypoint_flag Withheld_flag ScanAngleRank UserData PointSourceID

The errors(?)/warnings I get below also show up with cloudcompare. I'm not sure why some points are considered to be outside the bounding box or elevation range. it might be the way lasreader interprets something. my header looks like this

ply
format binary_little_endian 1.0
comment created by Fraunhofer IIS
element vertex 1292930
property float x
property float y
property float z
property uchar gray
element face 0
property list uchar int vertex_index
end_header

[Jean-Romain]

There are, at least, two very good reasons why lidR will not rely on .ply files

• the .ply files don't have a header that describe their content. For example the spatial extent of the points is not documented. Thus you need to read the whole file to know the area covered by your file. Now let say you have 1000 files and you need to extract a subset within a disc. How to do that? You necessarily need to fully read all the 1000 files. This is insane.
• there is not spatial indexation with .ply file. Spatial indexation drastically speed-up the queries. https://cran.r-project.org/web/packages/lidR/vignettes/lidR-computation-speed-LAScatalog.html

I enabled the reading of .ply files but doing so I also enabled to build a LAScatalog from a set .ply files. This technically works thanks to the seamless interface provided by laslib but this will fail in subsequent processing because the header of .ply files are false header wrongly populated especially the spatial extent. So, for the moment it is an undocumented feature.

. I'm not sure why some points are considered to be outside the bounding box or elevation range

Because there is no bounding box actually.

[dschneiderch]

That error makes sense now and I can see the disadvantage for general processing. It also explains why using the catalog processing chain did not work when I tried it.

Thanks again!