I am using Pix4D for the first time. I am working on a dataset of about 200 images. The external position and orientation of the images have already been computed to centimeter accuracy by the data supplier. I have an EO file and a GCP file in the CRS ETRS89 utm zone 32N + NN2000 (vertical datum). As Pix4D mapper does not support the NN2000 vertical CRS, I have set the vertical datum to arbitrary for both the images and the output/GCP. I set the initial processing calibration method to “Accurate Geolocation and orientation” and set both Internal and External parameter optimization to “None” as I trust the suppliers work.
However, after completing the initial processing step, the imported GCPs are much higher than the cloud. The difference is enough that is was quite challenging to find the GCP marker in the images. By marking the GCP in the images where I could find them I get a “Error to GCP Initial Position” of [0.709, 4.161, 597.764] meters indicating the shift is almost competely vertical. The shift is to big to be caused by a simple mix up of ellipsoidal elevation and msl height(The geoid height is reoughly 40 meters at this location). The computed GCP height is -268 meters. In my mind this seems to indicate that the problem is in the image geolocation, not the GCP coordinates. I am at a loss as to what could cause a vertical shift of the size. Does anyone have any suggestions as to what may be the cause?
I may be misinformed about the “reoptimize” function, but I’ve understood it that this is used to optimize the initial position and orientation after adding new information such as manual tie points and GCPs. Is this correct? To answer your question, I have not pressed reoptimize as I trust the initial position and orientation give by the supplier and really only want to use the GCPs more as checkpoints really, to check that I’ve done everything correct.
I may have been a bit unclear in my explanation. The initial position and orientation delivered from the supplier has been documented to be accurate within a few centimeters. As I am assuming that this company has done the job right, my expectation was that when processing using Accurate Geolocation and orientation” with both Internal and External parameter optimization set to “None” then the position and orientation given by the supplier would be used directly. When I then import the GCPs that the supplier used, I would expect the error between the GCP coordinate and the true GCP in the images to be in the centimeter range. However, the extreme vertical shift seems to indicate that something went wrong.
I think I might have a lead on the problem (or parts of the problem)
The supplier has given the euler angle rotations in order Omega (Primary), Phi (Secondary) and Kappa (Tertiary). I found here that Pix4Dmapper uses the order Kappa, Phi, Omega. This would account for the bigger errors in the initial position and orientation.
Question: Does Pix4Dmapper allow the user to set the euler angle order, or must I somehow alter the angles in advance to change from Omega, Phi, Kappa to Kappa, Phi, Omega?
Hi Bjorn,
First I do want to let you know that the image acquisition is not ideal. Basically, the overlap is insufficient to guarantee quality results.
Mapper can read Omega, Phi, Kappa. So you should not have to manipulate orientation values.
As for the vertical, I would first set all of your GCPs to Checkpoints. Then reoptimize. The Checkpoints will not be used to calculate the model but rather it will be an independent check for accuracy. This way you will be able to determine the exact errors for the horizontal and vertical.
If the vertical is showing a significant error then I would check to see what vertical coordinate system the images are acquired on. Is it using the WGS 84 ellipsoid or something else? This needs to be set accordingly in the image properties.
Thanks for taking the time to respond. I know I’m not giving you too much to go on.
I found the root to most of my issues I believe. The camera model that was automatically loaded when importing the images was not correct. It was an UltraCamEagle mark 3, but not the correct model, so the focal length was wrong. I don’t know why this happened, but I see here that UltraCamEagle Mark 3 is not on your list of supported camera, so that might be why Pix4D mixed the f120 model with the f100 model. I should of course have checked this properly, but it did not occur to me.
I manually edited the camera model as best I could from the correct camera calibration documentation. I processed step 1 again with no external paramater optimization and “All Prior” internal parameter optimization. My thought was that as I am still unsure if I set the camera model 100% correct, I should allow some optimization. The major issues resolved themselves. Check points are now off by mere centimeter in the horizontal, but systematically about 1.0-1.4 meter off vertically. So there is major improvement, but still an issue. I therefore set the Checkpoints to be 3D GCPs, marked all GCPs, and reoptimized. The results were excellent with GCP errors of max 6 cm vertically. So I am generally very happy, but I really want to understand the issue at hand here. If I understand correctly, the only parameter Pix4D could have chenged when I reoptimized was the internal parameters. The external parameters were “locked”. Is this correct? If so, it makes sense to think that the only issue remaining is setting the camera model 100% correct, assuming the calibration report I have was correct. I could of course use the optimized internal parameters, but the many of the interal parameters are quite correlated (from the quality report) so finding the “true” internal parameters might be difficult this way.
Does my logic seem right, or am I missing something?
To answer your question about the vertical CRS: Both GCP and image geolocation elevations are give as height above the NN2000 geoid, so the vertical system of both is set to “arbitrary” in Pix4D.
Why don’t you try Internal parameters “All” and compare the results? Just to see if you end up with better accuracy. I don’t know the Camera Optimization you got but it may be worth trying.
Taking int account that you flew a corridor, you could also try activating Geometrically verified matching, under first step, Matching. To see this make sure Advanced feature is on at the bottom of the menu.
Are you open to posting the images and metadata file online? I think I can help, but it would be easier to do it in realtime. I’ve dealt with the ultracams before and have successfully entered camera models (although this, in and of itself, was trial and error). If you’re open to me taking a shot at it, I can privately send you a dropbox link. Let me know what you think.
I’d be grateful for your help. As I believe the remaining errors lie either in the camera model, or in the external parameter files, you may have had to deal with simmular issues before. Feel free to message me the link.
I am trying to catch up with the issue.
If I understand correctly your problem is with the initial and computed vertical geolocation of the images. Is this correct? What is the workflow your supplier followed to give you the geolocation of the images? Did they use PPK workflow or just and RTK drone?
Yes the issue is with the initial accuracy of the image orientation after importing accurate geolocation and orientation. I expect the error in GCP coordinates from the input coordinates to the computed coordinates (from marking GCP) too be very small, as the documentation from the supplier indicates errors in the range 1-8 cm. This leads me to believe that I’, either importing the EO data wrong, that the sequence of rotation of the EO data is wrong, or that I am still unable to type in the correct camera parameters (which I doubt at this point).
The supplier used a PPK solution (from a airplane) and GCPs to compute the EO. They report a remaining GCP error of a few centimeters. They process the geolocation and orientation in Trimble Match-AT. They are a very reputable source and I know that collegues have processing their data succesfully in Trimble Match-T. However, I know that their orientation is outputted in omega, phi, kappa with a XYZ rotation sequence, and I believe Pix4D uses ZYX. However, as I get within 3-4 meters using the EO as is, I find it hard to believe that the sequence is wrong (as I would expect the errors to be much bigger if the sequence is wrong), but I may be wrong here. I also know that the supplier has applied correction for refraction and curvature, but I don’t quite know how that would affect my results in Pix4D.
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.
