Hi. We are working on a dataset with the following (so far):
static LiDAR point cloud, georeferenced on a known CRS with EPSG code
ground control points: fixed (!) and immovable coordinates.
some thousands of photos from UAS, shooting mainly downwards but also upwards (like 10% of the images look upwards).
The item is a vertical structure.
If we bring those GCP into the alignment, RealityCapture is the one and only software which moves them, instead of keeping them fixed.
The GCP are collected from the laser scanner point cloud: at a first laser scanner import (and alignment, but please note that laser scans position is exact, so they are imported as exact and fixed item with known position and alignment, we didn’t align the scan positions into RC) the GCP are placed exactly where they should be.
If we try to align another component (composed just by images) and we place the GCP onto the images in order to align the images component to the point cloud (laser scan) component, RC moves the GCP of even more than 1 meter!
Something’s missing here, RealityCapture is the only software that doesn’t manage ground control points as they should.
Is there anyone that could explain us how to manage those points, so we can help the components alignment with real coordinates?
Hi @RicTRK
As you mentioned that GCPs are based on the laser scan point cloud, does it mean that it wasn’t measured by other method?
If so, are you measuring those in RealityCapture? Then, are you changing the setting for the control point (then need to be changed to ground control) and their coordinates need to be set to an actual value (as after changing the control point to ground control its initial coordinates are zeros).
Can you show some print screens from this project (3D view, 1Ds view with selected GCP).
As you are using drone images, are you settings the camera priors to unknown? As drone’s GCP is not so precise and you are scanning the vertical structure.
We imported the ground control points as “ground control points” directly from Workflow → Import → Ground Control.
The GCP have been extracted from Riegl RiScan Pro point cloud project, and they are reliable as a GNSS RTK survey.
Please find attached a pair of screenshots.
Is there a reason why they move, instead of stay as fixed points which can be placed onto the images to align a photo component to the laser scanner point cloud?
When the position from the images and GCPs is too different, then it is possible that it will be moved.
You can try to turn off the camera priors, also set the higher weight or set the accuracy to smaller value.
Can you show also the actual position for that GCP?
Also, you mentioned more print screens, but there is only one attached.
Thanks for the support. I cannot add more than one screenshot per reply, so I just left the most important, the other one was related to import GCP settings, which is not so relevant.
We tried to exclude camera priors georeferencing, then add GCPs on photos in order to move the component onto the LiDAR point cloud: this is when we found out that the component made with the images doesn’t move as expected, instead it moves the GCPs (even raising the weight to 100, 1000 or more).
I think there is some strange behaviour in RealityCapture, compared to all other photogrammetry softwares. A control point with known coordinates is a fixed point. Placing it onto the images should move the sparse cloud made by the photos to match the ground control points.
Do you have set the project coordinate system properly?
After adding GCPs, are you providing a new alignment?
Are the GCPs placed properly over the map view? Also the laser scans?
What is the actual position of the GCPs?
Yes, CRS is set correctly. Yes, we made an alignment after GCP import, and the GCP are correctly placed over the map.
LiDAR point cloud is not visible on the map, but it’s correctly georeferenced since we already processed it with another software (iTwin) and, afterwards, we CAD designed on the point cloud.
Please consider that we’re using exactly the same dataset used in iTwin, whereas iTwin rebuilt perfectly the object, while RealityCapture seems to being not able to match even just a part of it.
We think that, actually, RC can get a result, but we cannot figure out how to properly use the (fixed) GCP (which should be, in fact, fixed) and go ahead with our process.
Are the laser scans part of this project? If so, you should see the camera poses in map view in a proper position (not the point cloud).
Also, it could help to add there some print screen of 1Ds view and 3D view. Also, the value of actual GCPs’ positions.
Are the GCPs also placed over LSPs in RealityCapture? On how many images are those GCPs placed in general?
Are you processing still the same project, or each iteration is a new project? Can you try to use the Force component rematch setting in the alignment settings?
I suppose this will be something simple missed, as the GCPs should work there.
Yes, the laser is part of the project. We can see the scanner cameras (by the way, we should exclude them from the alignment).
Due to classified data (regulated by a contract) we cannot share screenshots showing the actual object, we should privately share the data or get in touch and share the screen.
The GCPs are correctly placed onto the laser point cloud. We placed the GCPs on as many reasonable images as possible, I would say several tenths.
We made a first project with the LiDAR, which is the master project; then we make a new project for each part of the asset that should be resolved down to one single component, then we export the registration and import it, one by one, into the master. Each step should process the correct component integration (I mean that the imported component is aligned to the laser point cloud) and this is where we usually need GCPs and they don’t behave as expected.
We didn’t try the force component rematch so far, we’re going to try.
