Pix4Dmapper reads information from the image EXIF data. It reads both standard EXIF tags and Pix4D defined camera XMP tags.
In the XMP tags, you will find the orientation and accuracy-related information written in the parameters Xmp.Camera.Yaw, Xmp.Camera.Pitch, Xmp.Camera.Roll, Xmp.Camera.GPSXYAccuracy and Xmp.Camera.GPSZAccuracy: Specifications of xmp.camera tags.
To make sure your images contain such information, you can use this tool by dragging and dropping one sample image and looking for the necessary parameters: metapicz.
Indeed, the accuracy values are in the metadata. Have you also tried processing the project with the calibration method Accurate Geolocation and Orientation? I think the software should be able to pick up the accuracy of the geotags. More details can be found here: FAQ on the accurate geolocation pipeline.
This means that the images do not have accurate geotags. Do you have a sample of the image geolocation file? The values should indicate very accurate geolocation and orientation, as shown in the screenshot below:
Hello,
I am having similar issues, where Pix4D is shifting the images irrespective of the high-accuracy PPK geolocaiton through PropellerAero.
We are working in an Australia co-ordinate system (GDA94) and an Australian Geoid grid (AHD09). The input file is already converted to the co-ordinate system and the geoid. I select the co-ordinate system we are using (GDA 94 MGA Zone 54), and currently select “Arbitrary” as the vertical geolocation.
I find that these settings are producing poor accuracy compared to the cloud processing through PropellerAero. The reason we are not cloud processing is that we want to be able to crop the data and edit the point cloud, but data accuracy takes precidence.
The data MUST be in the aforementioned coordinate systems to meet our clients requirements. What settings do you recommend in Pix4D to achieve the proper map accuracies from PPK?
The processing workflow for RTK should be similar to PPK. In the end, you are dealing with image datasets that have highly accurate geotags, only their origin differs.
If you are getting some shifts, I would suggest first double-checking the PPK correction process and make sure the appropriate data was chosen:
the rover file (rinex data from the drone) - ensure there was no strong wind that induced vibrations to your drone.
the base station file (rinex data from a fixed base station) - this should be as close to your study area as possible.
broadcast ephemeris data (precise satellite navigation data) - this acounts for orbital errors and should be reliable.
The last resort would be to correct the shift by including GCPs in the project. RTK/PPK geotags in consumer drones is a relatively new technology and the workflows for using them have not yet been clearly defined in the industry. To what extent they can replace GCPs as a means for high accuracy in mapping is not thoroughly understood. In general, the best practices would still require the use of GCPs and checkpoints to meet proven absolute accuracy standards.
However, the benefit of RTK/PPK image geotags is that you can reduce the number of GCPs collected for a given project.
In order to import image geolocation with the accuracy values, the orientation angles need to be determined in the file as well. If the orientation angles are written in the EXIF of the images you can create a project in Pix4Dmapper and use the To File… option to export them in a text file. Then include the exported omega, phi, kappa angles in file with PPK geotags and use the From File… to import everything.
If your final goal is to deliver accurate results based on the already transformed values of image geotags then I would recommend changing the vertical coordinate system to Arbitrary in the image geolocation and outputs coordinate system menu. This way no transformations will be done during processing and results will be in the same reference frame as PPK geotags.
Hello
I’ve just processed images collected by a DJI P4RTK drone.
Indeed after the first step of the processing, I noticed the following problem: model divided into two blocks (see capture).
Have you ever had such a problem. I request your help to solve this problem.
Good morning, dear @Kapil_Khanal .
What seems a little blurry to me is that I had the same problem before when I used a non RTK drone. I ended up with two blocks almost perpendicular to each other.
Which exit for me dear community?
A block is a set of images that were calibrated together. Multiple blocks indicate that there were not enough matches between groups of images to provide global optimization. When a project contains multiple different blocks they may not be accurately georeferenced relative to each other. A project should ideally contain only 1 block.
Now when is the problem with optimizing the camera settings?
Often when I process some projects, I end up with a camera settings optimization ratio in the order of 100/100 or more times, when all the images are calibrated.
So what’s the way out for this kind of problem my dear brother?
Hi @alkassoumoutari,
These are very interesting questions, I will be glad to give some hints/help so that you can move on with your project.
However, you may also want to look into one of our paid training services. Our trainers can help develop your workflow and answer any questions you may have about complex topics related to processing.
Learn more about our workshops and personal training offering here.
If you have a valid license, you could also reach out to the personal support here. It would be easier to communicate and deal with your issue. Make sure to provide quality reports, few screenshots of the issue while reaching out to personal support. If there is anything useful, I would share the result on this page later.
Hi thanks for your answer. I did the process as you mentioned but when I upload come check points to verify my process I have 1.5m of difference in height (z) between the the check points and the original measure.
I am also seeing a horizontal shifting final outputs. The outputs are very precise but shifted 1.5 meters. I can easily shift the outputs back and make them accurate. I am just trying to have a better understanding of why this happens.
“What could cause a big offset when comparing the results with checkpoints?” the link above does not work? I wanted to read more about it.
I am a very experienced land surveyor. Using Trimble R10 base and P4RTK. Area is over a drone test area we made with many more photo control points than needed. It has both bare earth, vegetation, and hard surfaces.
I have a flight where both the RTK will miss the ground control and also if I run PPK on the same images they also miss. But both are very precise and I can move the final data easily enough. I am just puzzled at how this happens.
This has happened before on other areas I have done work. But otherwise most of the time the usual work flow and the results all are right on top of the ground control.
I process all the images in wgs84 and export in that, then afterwards I check it all in Global Mapper and use wgs-84 ground control. (I can re-project later into whatever coordinate system I want and works with no issue. So this is not a coordinate system matter.)
my expertise is in using metashape and that is where I first found this issue. I wanted to rule out it being in the image processing so tried various methods and same results. Then I decided to run the data here in Pix4D, as I intended to learn this app as well. Well Pix4D also misses the ground control. but it is also precise. by the way PIX4D is very easy to use, nicely done.
Looking for feed back and suggestions or if anyone else has this happen? I am mostly trying to understand this as best I can. I am working on writing a drone data processing manual.
Could you provide more information on the coordinate systems you use in the project (GCPs and outputs)?
We had some users contacting us regarding similar issues and the offset you get could be related to the fact that horizontal grid deformation and corrections are not supported in Pix4Dmapper. But I will be able to say more once I got more information on the coordinate systems you use.
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.
