Hello all. I hope this question finds you well and thanks in advance for your time. I have done several hundred projects using p4d and C3d, and for the first time, have points imported from .txt that are not matching the spray painted field markers that correspond to our surveyed control points.
This project encompasses a large hospital complex and was the most time and resource intensive job thus far in terms of processing.
I’ve attached a video here showing details of the issue
“…was the most time and resource intensive job thus far in terms of processing…”
First off, please post your quality report. Just about everyone here that can give you sound advice is going to be doing that based on what they see in the quality report.
Your video looks like your marks are off by roughly the same amount that mine are off when I don’t use ground control. Are you sure that you re-optimized after marking control? Did you merge subprojects and reoptimize after?
Did you change your processing settings on this project, since I’m guessing you were sweating the processing time if this is the biggest project you’ve done to date?
Automatic “Rematch” (Initial Processing->Calibration) is disabled on projects over 500 images. This could be a concern I suppose, but the ortho in your video doesn’t appear to have errors in it that I would expect here.
Anyways, my guess without seeing the quality report would be #1 (control was marked, but didn’t reoptimize after). That mistake can happen to a brand new user just as easily as someone with a lot of experience in a production environment.
Sorry guys, thanks so much for your time. I thought I already had uploaded this report.
Additional info of possible relevance - This project data was gathered using DroneDeploy rather than the stock DJI app, which we have used a few hundred times largely without incident. I also have 2 other projects since this one was begun, and both of those had points that were not located properly after creating points from .txt file.
This issue is confusing because the points in the pix4d environment appear to be properly located, just not in the C3d environment. The .tif and mosaic match one another perfectly.
For completeness Ill also mention that the orthomosaic was too large to be imported into C3d, so I put each tile in individually.
Here’s your problem right here (Looks like #1 from my first post in this thread). No control points included in the results. The “yes” means that your images are geotagged, “no 3D GCP” means that those control points you marked in the raycloud editor were not factored in to your results because you didn’t reoptimize.
It’s also good practice to “generate quality report” after reoptimize, since that is not done automatically like it is after processing each step. If you have an issue after reoptimizing, you want to catch and correct it before you waste all that time processing steps 2 and 3.
edit: I’m confident that the comments above will fix your issue, but other observations from the quality report:
It looks like you did this with a Mavic 2 and Phantom 4 Pro? Did you process these images in separate projects and then merge them?
I see that you’re using a computer with a Xeon processor. I’m not sure if this is still true (and maybe support can chime in here), but the Xeon processor was explicitly discouraged from use by Pix4d ~5 years ago in their support docs. I had a workstation that had one and processing times were definitely longer with it than my current setup.
Your output coordinate system is using EGM96 geoid for vertical. Pix4d recommends that you use “arbitrary” as the vertical option when processing with 3D control points (unless that has changed in the last year or so)
The general consensus of the community is to use “all prior” setting under calibration options for internal camera parameters. I do this with Phantom 4 Pro flights and it definitely has improved results and/or made it easier to catch errors in ground control points. I’m not sure if this is the recommended option for something like a mavic 2 pro.
I see that you’re generating the DTM in pix4d, as well as contour lines. If you haven’t noticed this already, be cautious about using that and trusting the contours. Recommend you purchase something like Global Mapper + LiDAR module as a tool to do some manual surface building, instead of relying on the automated DTM process in Pix4d. (No critism of Pix4D here…I’ve never seen an automated tool like that work in any software for photogrammetry-derived point clouds. It always takes elbow grease).
Hello. I am in the middle of a civil engineering project and have a problem I have not seen before.
I am importing field shot GCP coordinates into the c3d project, but they are not coming in over the spray painted targets in the orthomosaic. I have done many of these projects but am unsure how to proceed’
Indeed, as Derrick said the quality report shows that the GCPs are not taken into account in Pix4Dmapper. This is why you see the offset.
To correct it, you need to add the GCPs, mark them and reoptimize:
Regarding the vertical coordinate system and the comment “Your output coordinate system is using EGM96 geoid for vertical. Pix4d recommends that you use “arbitrary” as the vertical option when processing with 3D control points (unless that has changed in the last year or so)”
We recommend adding the reference that reflects your images’ altitudes (geoid or ellipsoid) and the one that reflects the GCPs’ altitudes (geoid or ellipsoid). If your images or GCPs use a geoid that is not in our database (egm84, egm96 or egm2008), then you may need to use arbitrary or the Geoid Height Above the Ellipsoid function. The same applies to your output coordinate system.
Here you can find more information about the
Let us know how it goes when you reoptimize the project with the GCPs.
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.