I am trying to process iPad Pro Pix4D Catch data (photogrammetry plus LiDAR) that was captured using the device’s GPS in WGS 1984. I’m using Pix4D Matic software for processing. When I process the data without georeferencing, it generates a dense point cloud (around 117,260,000 points), a good orthomosaic , and a DSM. However, when I try processing it by georeferencing with around 5 control points 4 at the corner and 1 at the middle using the NAD 1983 (2011) Texas South + NAVD 88 coordinate system, I notice some noise in the data, a significantly reduced point cloud (around 121,035 points), and the DSM and orthomosaic contain holes and noise
The camera positions plot seems to show that the initial and optimized cameras are really far away from each other. They should be more or less at the same place though, could there be something off with easting/northing that were in the wrong order for GCPs?
There are only 4 GCPs marked and the marks do not seem to be reliable, you can check that in the “Verified/Marked” column. The reprojection errors are really high too, seeming to indicate that something is off (note: no step seems to be outdated (i.e. in orange at the end), so it’s not a question of using reoptimize to take marks into account. As the project is on a beach and the target look really similar, I’m wondering whether the right images were marked for each target. Can you please double check?
I’d recommend to make sure there is a clearly visible number on the targets (hard to see based on the quality report), so that it’s easier to mark them correctly.
I realized something after reading the following blog:
The initial camera position is far off because the data was captured using an iPad Pro (Wi-Fi only) in a remote location without Wi-Fi access. I discovered that the iPad Pro (Wi-Fi) has a digital compass (iBeacon microlocation) but lacks a GPS/GNSS module. Wi-Fi-only models can only infer their location based on a database lookup of neighboring Wi-Fi networks or the geographic location of a public IP address.
When I captured the data, the device assumed the location was a null island (0, 0).
Regarding the GCPs, I verified them using ArcGIS Pro in the local coordinate system, and they are correctly aligned. I also double-checked each target in the correct order by visualizing the initial position and marking the location of each.
I tried processing the data again following your guidance, but I’m still encountering the data gaps, as shown in the attached report.
Could the distance between the initial and optimized locations be the sole reason for this issue? However, I believe that distance shouldn’t impact the results this significantly. Beach_Scan_georef_second-quality_report.pdf (3.4 MB)
Okay, that explains why we saw a difference between the initial and optimized positions when there were GCPs.
It’s weird though that the issue persists, looking at the last report, I see you marked some more images and the total errors decreased, but we’re still not there…
Looking at the GCPs and CPs, I see that there are still a lot of marks that seem to be unverified (circled in black) and high reprojection errors. This seems to indicate that either there are wrong marks, in that case you’d need to correct how they’re marked in the images (zooming in before marking usually helps), or there are not enough marks from different points of views to the same GCP. For the latter, you can select a GCP and check the rays that go to it, ideally, there are yellow rays (it means you marked the point in the image) coming from all directions, which means it should better minimize the error.
There may still be an issue related to the coordinate reference system and the geotags…the best in this case would be that we can set the coordinate reference system of the images to “arbitrary CRS” and remove the geotags of the images if needed too, so that they do not have an influence on the processing. Those are two developments that we still need to address, I hope to have them by end of Q1 2025 though. That doesn’t help for right now…I’ll reach out to to coordinate reference experts in the team to see if they have a suggestion.
Okay, so here is the information I got from the CRS specialist:
Texas is around 100 deg west and 30 deg north. The distortion of 0,0 in EPSG:6585 is about 11%, and the meridian convergence (the angle between north and Y axis) is about 44 degrees (and you are lucky, because transverse mercator is much worse in that particular case).
Setting the CRS of the project to Texas South and projecting the cameras from null island will produce… bad data.
We definitely need to look into this on our side, e.g. by not sending data to null island when there is no GPS in PIX4Dcatch. That said, right now, a workaround would be to strip the images of its geotags and then try again. I haven’t done this recently, but I know there are command line applications such as exiv2 and exiftools that may be of help
One more idea, how about you use the “Offset camera positions” in the camera table, you select all cameras and then you offset them to be closer to Texas (instead of the Null island) with right click > offset camera positions. Then the issues in the coordinate transformations should be much lower.
I tried offsetting the camera position to a nearby location within Texas, near my study area, using coordinates of 27.1728 latitude, 97.3697 longitude, and an ellipsoidal height of 0 m. However, it ended up placing the cameras in an unfamiliar position in Asia. Could this be a bug, or is there something else I might be overlooking?
We have a few ideas on how to fix this in the future, but we’d need the dataset to make some experiments. Would you be willing to share the data with us? (images, project, GCPs,…)
Yeah, I was missing the negative in longitude. This resolved the issue, although the initial orientation is in different direction. The calibration solved the issue. Thank you for your coordination.
I was using the data for research purposes, but I can share it for experimental purposes since I have additional data captured in a similar manner. Georeferencing might be challenging because all the targets are identical, so I used ArcGIS Pro, along with camera positions and image numbers, to verify the GCPs. Since this is a public community blog, I can share the data privately via email or another secure method.
These cookies are necessary for the website to function and cannot be switched off in our systems.
They are usually only set in response to actions made by you which amount to a request for services, such as setting your privacy preferences,
logging in, or filling in forms. These cookies do not store any personally identifiable information.
These cookies allow us to count visits and traffic sources so we can measure and improve the performance of our site.
They help us to know which pages are the most and least popular and see how visitors move around the site.
All information these cookies collect is aggregated and therefore anonymous.
If you do not allow these cookies we will not know when you have visited our site, and will not be able to monitor its performance.
These cookies may be set through our site by our advertising partner (Google).
They may be used by Google to build a profile of your interests and show you relevant adverts on other sites.
They do not directly store personal information but are based on uniquely identifying your browser and internet device.
If you do not allow these cookies, you will experience less targeted advertising.
