I recently downloaded Blaze version 1.1 and noticed, in addition to .E57 and .PTX, that PLY format also appears to be supported. Attempting to import this format was unsuccessful, throwing the error that “the file does not contain any cameras”. I am currently using a LiDAR scanner that does not provide camera data, however if I knew what RC is looking for, I could embed it into the file using another stream. What is RC looking for in order to correlate point cloud vertices to images? I was presuming ordered coordinates with RGBA values would be sufficient.
Hello dear John,
sorry for letting you wait. I have gathered detailed information about this function and here you go:
format documentation:
https://en.wikipedia.org/wiki/PLY_(file_format)
supported formats:
ascii
binary_little_endian
binary_big_endian
supported version:
1.0
mandaroty fields:
vertex
camera
phoxi_frame_params | camera_resolution
supported property types:
char
uchar
short
ushort
int
uint
float
double
uint32
unsupported property type:
list
Thank you for the additional details. It appears that RC supports exclusively PhoXi camera exports. I have attempted to track down their specification, but cannot find anything. I am stuck having to wrap our exports in E57 format, which is fine, but it is taking longer than usual, since the export must happen “on the device”, and it has had a hard time using the C++ libE57 library (which depends on Xerces and Boost).
Hopefully, I can get more information on how to format a PLY properly in order to include correlations for cameras.I have found the following output on the PCL site, but it is not clear how all of these values map to rotation, transform, and intrinsics:
ply
format binary_little_endian 1.0
obj_info Photoneo PLY PointCloud ( Width = 2064; Height = 1544)
element vertex 3186816
property float x
property float y
property float z
property float nx
property float ny
property float nz
property uchar red
property uchar green
property uchar blue
property float Texture32
element camera 1
property float view_px
property float view_py
property float view_pz
property float x_axisx
property float x_axisy
property float x_axisz
property float y_axisx
property float y_axisy
property float y_axisz
property float z_axisx
property float z_axisy
property float z_axisz
element phoxi_frame_params 1
property uint32 frame_width
property uint32 frame_height
property uint32 frame_index
property float frame_start_time
property float frame_duration
property float frame_computation_duration
property float frame_transfer_duration
element camera_matrix 1
property float cm0
property float cm1
property float cm2
property float cm3
property float cm4
property float cm5
property float cm6
property float cm7
property float cm8
element distortion_matrix 1
property float dm0
property float dm1
property float dm2
property float dm3
property float dm4
property float dm5
property float dm6
property float dm7
property float dm8
property float dm9
property float dm10
property float dm11
property float dm12
property float dm13
element camera_resolution 1
property float width
property float height
element frame_binning 1
property float horizontal
property float vertical
end_header
It looks like the PCL library may be used to write PLY with cameras:
Well I hope you’ll find the correct way, if not I may ask the development team for this, but the integration to your hardware is something they possibly could not know about.
I will be happy to share results once this is working. If possible, could your developer team please let me know what RC is expecting to see in these fields:
element camera 1
property float view_px
property float view_py
property float view_pz
property float x_axisx
property float x_axisy
property float x_axisz
property float y_axisx
property float y_axisy
property float y_axisz
property float z_axisx
property float z_axisy
property float z_axisz
I know the px/y/z is the projection coordinates. Are the remaining values a transform matrix? If so, it’s not the standard 4x4.
I will try to have a look at this with the dev, please be patient meanwhile.
I’m also having an issue importing a PLY file. I also get the error that “the file does not contain any cameras.” Was there any success adding the PLY camera data?
Hi Barrverian,
it is not possible to import .ply format laser scans into RealityCapture. We support this formats: PTX, E57, and ZFS/ZFPRJ. It is not possible to import just a point cloud into RealityCapture without the information about cameras, since this is a photogrammetry software.
Thanks for the answer, .
I see .ply listed in Reality Capture 1.2 under the supported formats. If not supported, it might be best to have it removed from this list:
If you have the info about cameras and it is ordered, then it should be possible to import. With what kind of scanner did you create the PLY file?
Hi there. Has anyone had success recently with importing .ply files into RC? I’ve been working with this for a few days now without any luck. Here’s what I’ve tried:
- Following a guide on .ply files here: http://paulbourke.net/dataformats/ply/, I’ve generated the following ascii test file,
ply
format ascii 1.0
element camera 1
property float view_px
property float view_py
property float view_pz
property float x_axisx
property float x_axisy
property float x_axisz
property float y_axisx
property float y_axisy
property float y_axisz
property float z_axisx
property float z_axisy
property float z_axisz
element camera_resolution 1
property float width
property float height
element vertex 4
property float x
property float y
property float z
property uint red
property uint green
property uint blue
end_header
0
0
0
1
0
0
0
1
0
0
0
1
2
2
0 0 0 255 0 0
0 1 0 0 255 0
1 1 0 255 0 0
1 0 0 0 255 0
- As visionarymake alludes to above, I’m assuming the properties in the ‘camera’ element represent a transformation matrix, with px/py/pz representing the position of the camera, and x_axisx etc. representing the elements of a rotation matrix or DCM. Note the line endings in this file are line feeds (LF).
- I’m able to open the above file in Cloud Compare, which correctly acknowledges 3 elements and 20 properties. RC loads the file as well, however the cloud does not appear in the ‘Input’ window.
- I tried exporting the above file in .e57 format using Cloud Compare, but when I try to load into RC I receive an ‘operation failed’ error.
Hoping someone else has figured this out in the last 7 months. I’ll add my vote to the existing RC feature request as well, https://support.capturingreality.com/hc/en-us/community/posts/360010833240-Suggestion-on-third-party-software-to-convert-unordered-point-clouds-to-ordered-for-RC-import.
Thanks
Hi thitch2,
PLY format for laser scans is just for structured ordered data (for example scan position of terrestrial laser scanners).
Can you see in CloudCompare the GLS/TLS information in the data tree? Also, it is possible to create E57 from CloudCompare, but it doesn’t save the scanner position in the format.
Hi Ondrej,
Thanks so much for your response. I’m unable to see GLS/TLS data in the CC data tree. A few follow-up questions for you below,
- Based on your experience writing this FAQ, https://support.capturingreality.com/hc/en-us/articles/360020653080-How-to-import-any-scan-data-to-RealityCapture-using-CloudCompare-and-Faro-Scene-How-to-create-ordered-point-cloud-from-unordered-, am I simply missing some required element(s) in my test .ply file above, which if included would cause RC to recognize the file as `organized?’
- I have read, for example here,https://www.mathworks.com/help/vision/ref/pcwrite.html#:~:text=filename%20%E2%80%94%20File%20name&text=It%20converts%20the%20format%20because,file%20in%20a%20PLY%2Dformat., that the ply format does not support organized point clouds. If this is true, then attempting to move forward with the ply format is futile, and I would need to follow your above FAQ to export e57 files with the required information (as you mention, CloudCompare does not seem to be exporting e57 files with the required info).
- Finally, I see that RealityCapture 1.2 was recently released. Are you aware if the new release allows for import of unorganized point cloud scans?
Thanks again for your help.
Hi thitch2,
I am not sure how it works in PLY. What I know is that you need to have camera information in the file and it has to be baked in it. The mentioned workflow is for creating those laser scans/cameras positions, something like fake them if they are missing in the original data or data from movable scanners. Ordered means it has a 360° scanner position baked into the point cloud data per scan position (when you are moving with a backpack or using a car there are no actual scan positions, just georeferenced point cloud data). In most cases, 3D laser scanners on cars or backpack laser scanners are producing unordered data, because no 360 laser scan position is really calculated. RealityCapture only natively supports ordered data from terrestrial static laser scanners like Faro S130. We do not support any data from devices like Faro Freestyle 2, which are producing un-ordered scan data (each 2d camera position is not recording during the scanning session or we do not have data from that session after export). The reason why RealityCapture requires knowledge about camera position is that it´s a photogrammetry software (we take laser scan data as camera positions, not as point clouds).
Regarding to second threat: https://support.capturingreality.com/hc/en-us/articles/115001483611-Laser-scan-import
No, it is still not possible to import unordered laser scans into RealityCapture
Hi Ondrej,
Again, thank you for the quick reply, much appreciated. Yes, I was trying to ‘fake’ the camera information in the above test file, via the ‘camera’ and ‘camera_resolution’ elements. However, I suspect I’m either still missing some information required by Reality Capture, or perhaps the file formatting is incorrect.
Perhaps there are plans in the works to build a point cloud alignment pipeline into Reality Capture? Different optimization algorithm, but in my opinion would really generalize the software for producing high-quality 3D meshes.
Thanks again, and take care.
Regarding to lase scans, I am not sure if it is defined just as camera, as it should be read in CloudCompare as TLS/GBL sensor and there is more information (like uncertainty, angular viewport, position and orientation)