I have collected aerial imagery using a DJI Phantom 4 and within the Properties of the images the altitude is displayed correctly, however, when I load them in to Pix4DMapper all of the altitudes are given negative values.
Can anyone shed light on why this is happening and a possible solution?
Hi Eldred,
The images that are saved on the drone’s SD card are geotagged by DJI. Regarding the Lat./Log. coordinates, the drone’s GPS saves reliable information in the image EXIF. There is no problem from that side. However regarding the altitude there might be some inaccuracies depending on the location when you are mapping.
According the latest news on our side that refer to the firmware v.1.7.0.90 and v1.7.0060 for the Inspire I and Phantom 3 Pro respectively, DJI now measures the absolute elevation above sea level using EGM 96 as the reference. This also applies to the Phantom 4’s firmware. DJI used to record the elevation above ground level but this is no longer the case. However the vertical coordinate is still not fully reliable. Indeed, we made testing in our office here and we found that the vertical coordinate is off by several meters that can reach an error of 100 meters. Some users noticed the same.
Note that this is just an offset meaning that the within the model, the accuracy is not affected, only the absolute location.
DJI released on April 7th new drone firmware, but as far as we know, the issue remains.
Therefore our developers suspect something wrong in the DJI EXIF regarding the vertical coordinates. As a consequence, we always recommend to process with ground control points (GCPs) in order to fix these uncertainties.
About using GCPs: https://support.pix4d.com/hc/en-us/articles/202558699
If you do have GCPs, you could get for instance 5 points from a Web Map Service server over your area (e.g. Daft Logic): https://support.pix4d.com/hc/en-us/articles/202560149
Regarding the negative values, it happened that the field referring to the altitude above sea level is actually called “Below Sea Level”, which might be confusing. They probably made a mistake with the reference name which seems to happen time to time.
There is a DJI forum post related to this issue: http://forum.dev.dji.com/thread-31960-1-1.html
A consequence is that when Pix4Dmapper reads the geolocation contained in the EXIF, the software is misled and interpret “below” as a negative value. Our suggestions using points to fix the vertical coordinate as mentioned above will probably solve this problem.
Regards,
I’ve experienced this too, and just posted my solution on a related forum post. Here’s what I said, hopefully it will help point in the right direction:
I ran into the same problem with my Phantom 4. DJI is recording into EXIF the GPS altitude, relative to the ellipsoid, which is very rarely accurate or useful for photogrammetry or surveying. I had photos showing up as below sea level as well, and inaccurate (ellipsoid-referenced) elevations throughout my study area. Thankfully, the barometer information is still present in jpeg metadata, but you have to make some tweaks to bring it out. Here’s how I did it, though there are likely other ways (note: some basic coding is involved):
I used exiftool: http://www.sno.phy.queensu.ca/~phil/exiftool/
This (freeware) application can be run from the command line, though I did it within R using “system()” to call exiftool.exe, though the same syntax should work. If you go the R route, exiftool.exe should be in your working directory.
You can view all the metadata tags with a command like system(“exiftool DJI_0807.JPG”)
You’ll see several tags, though the relevant ones are GPSAltitude, RelativeAltitude, and GPSAltitudeRef. GPSAltitude is referenced to the ellipsoid; you’ll want to replace this with RelativeAltitude, which is determined by barometer readings between the launch point and UAV position. You also might need to change GPSAltitudeRef to make it above sea level. This can all be done with the following line of code:
system(“exiftool -n -GPSAltitudeRef=0 -tagsFromFile @ -RelativeAltitude>GPSAltitude DJI_0807.JPG”)
NOTE: this will change the altitude to ‘above sea level’ whether it is or isn’t, so if you’re flying in the Dead Sea or somewhere like that, you’ll have to do it differently.
This will substitute RelativeAltitude for GPSAltitude, and in my experience Pix4D and other EXIF readers interpreted this correctly. It’s also possible to run this recursively on folders full of files, for example if for the final argument you use “photos/” (i.e., a folder) instead of “DJI_0807.JPG” (i.e., a file).
I recommend looking over the exiftool documentation if you have problems. Hope this helps someone!
JB
Hey Jeff,
We have a DJI Phantom 3 Pro and are experiencing similar issues. We have downloaded the ExifTool but cannot seem to figure out how to properly use it. Is there any part of the documentation that you would recommend really focusing on? Or would you mind contacting us privately to help resolve our ExifTool issue?
Thanks
Although the altitude is negative, the error is only related to a vertical shift (negative offset of several meters making the altitude negative). The best solution is to use ground control points (GCPs) to fix it and there are two alternatives if you do not have any. Please find more information in the articles below.
About using GCPs: https://support.pix4d.com/hc/en-us/articles/202558699
If you have issues to mark the GCPs in the rayCloud because of vertical shift: https://support.pix4d.com/hc/en-us/articles/206544136
If you do not have GCPs please refer to: https://support.pix4d.com/hc/en-us/articles/115000778603
While I can’t say that my solution will work every time, it absolutely addressed my problem. Using GCPs would be the best solution, especially for SFM, though this isn’t always an option, if for example like me you fly over open water where I can neither place GCPs nor borrow some from satellite imagery, for example. In the final link provided above by Support, “Editing the Image EXIF” is what my approach tackles, though outside Pix4D software using free open-source tools. Support, you may wish to examine my solution as well, and you could possibly make our lives easier by allowing the user to select which tag is used as elevation; that said, this is the fault of DJI, not Pix4D, don’t get me wrong.
As an example, I recently flew a survey at exactly 90 m above the sea surface, which of course should also be ~90 m above sea level. Reading the EXIF tags from one of the images produces a ton of info, which I won’t reproduce in full, but notably includes the following tags referencing altitude/elevation:
Absolute Altitude : +112.19
Relative Altitude : +90.60
GPS Altitude: 112.1 m Above Sea Level
In looking at other images, the discrepancy can be much larger or much smaller, and can also include negative values. Whatever the CAUSE, it’s clear that the “Relative Altitude” is the value relevant for image analysis, and is what we want Pix4D to use; 112.19 is not correct, and would lead to poor results without GCPs.
Through experimentation, it appears that the “GPS Altitude” tag is the one that is read by Pix4D, and is also what reports the altitude if for example you look at image properties in Windows. Therefore, I used the above solution to batch process all images, with the end result of correct altitudes for use in SFM and image analysis.
So, though this solution may not solve all issues, it will certainly solve some of them. Also note that this could change at any time with updated DJI firmware, so take with a grain of salt. Support, I think you should make your developers aware of this, if they aren’t already, as it’s an entirely simple fix to a problem that several seem to be experiencing.
Steve, happy to help, if I can figure out how to contact you… maybe google my name and send me an email?
I am having bad elevation results that sound a lot like what others have described in this thread.
|
|
I have assembled a dropbox folder for a problem I am having with elevation data. Dropbox link is https://www.dropbox.com/sh/ebe9n9122lohq55/AABkFgS7JFwRcjlQFHu2sBkRa?dl=0.
I have processed images from several different flights into a single Pix4D run, and have specified 5 GCPs after the initial run, where I discovered elevation data that was about 2x the range across the site that it should be. In my area of survey, the 4 lane highway should be about 40 meters above the sea, which is also in my survey. Instead I am seeing elevation of ~80 meters from sea level to highway. I read all the instructions on specifying GCPs, and picked two GCPs at sea level, two on the 4 lane highway, and one other at an intermediate inland point. I referenced a survey done 10 years ago, and took the elevation of those points from that survey (whose .dwg is in the dropbox folder) as the elevations of the GCPs, in meters above sea level. I generally trust the 10yr old survey. Also, I only need +/- 1 meter accuracy in elevation data. Better would be nice, but not necessary. However, the GCP process I followed did not seem to help.
My end goal is land planning view analysis, as shown in this video (https://www.youtube.com/watch?v=UAyEMGmIDSw) captured from SketchUp animation. Unfortunately the views are overly optimistic because the villas are 2x the height above sea level as they would be in reality. I have put in dropbox a Word doc with several screen shots from Pix4D desktop. Perhaps these will point out something to you that I am missing. Should I be using WGS 84, UTM Zone 12N? I see the vertical coordinate system is EGM96, which it says is ~32.8 meters above WGS 84. Does that make sense?
Any help or advice appreciated!
Kelly
|
|
Hi Kelly,
We followed up and replied to your request via our ticket system :).
Had the same issue.
Realised that while the altitude data is shown as positive the EXIF data is showing below Sea level, so on import it becomes negative.
Trying to find a solution
Hi Isaac,
I recently had a closer look at the EXIF files from a similar case and noticed that the altitude reference is set to “Below sea level”. DJI probably made a mistake with the reference name which seems to happen from time to time.
There is a DJI forum post related to this issue: http://forum.dev.dji.com/thread-31960-1-1.html
A consequence is that when Pix4Dmapper reads the geolocation contained in the EXIF, the software is misled and interpret “below” as a negative value.
You can check this, for example, with the tool exiv2.
Best,
Pix4D has provided an EXIF editor tool in their desktop software
essentially, make sure you have a confident number for the absolute take off altitude
export your exif data to file csv
open this into excel
find the correction for your first photograph, and apply the same correction to each photo altitude number
save the new column values over the top of the original column, and delete the wasted data
re-save
open EXIF data from file in Pix4D, then import the replacement data
@AP Procurement,
Another quick workaround that might be interesting is to manually change the altitude of the images directly in Pix4D software by following this procedure:
As a side note, following the above workflow will change all the z-values to the same value. Some precision might be lost but you should still be able to process the project and refine the final position of the project using the GCPs without facing difficulties.
ah Blaz - I didn’t realize that you could do this from the image properties editor directly - VERY quick
my system would only be necessary when I have combined runs from different batteries / altitude estimates (I LOVE that the DJI machines all use a rubbish vertical datum!)
Hi,
I have a question. I need to change the altitude absolutes for the relative altitude, because the altitude between diferents batteries are wrong, however the relativa is ok.
I have two kinds of photographs from different batteries and altitude. The altitude are between 24,5 and 25,5 for de double grid, no are exactly the same (these dates I obtained from the metadata).
I did:
-charge the photographs in pix4d
-Export the data on csv
-Open into excel
-Change the values in the column “altitude”, and save
-Click on “From File”, and put the modify csv.
However Pix4d showme this error.
Can anybody help me? The problem could be the “()” in the name?
If the problem is that, how I can eliminate the parentesis from the name of all the archives? Because is not possible eliminate the simbol through cmd or powershell.
Thanks
Hi Aplicaciones GRT,
I had a look at the error message and it looks like your file is correctly formatted. I also do not think that the parenthesis is the issue.
Which version of the software are you using?
Could you attach the .txt file here and I will have a look if I spot something.
Best,
Blaz,
Thank you for the reply.
I attached the file DataFotos.txt (177.5 KB) is which I exported from Pix4d.
And the DataFotos2.txt (142.7 KB) is the filed modified by me.
If can help you I attach the file with the metadata information which I extracted the relative and absolute information too.
out.txt (207.1 KB)
The version is the 4.5.6.
Best regards,
Diego
Hi Diego,
Could you add comma separator between the values and and try importing the file again?
At the moment the input file is formatted like this:
MVL20200721circulares(1).JPG -34.82676969 -56.23597364 30.8 -22.0984 -30.335 -128.797 5 10
Could you try:
MVL20200721circulares(1).JPG,-34.82676969,-56.23597364,30.8,-22.0984,-30.335,-128.797,5,10
Best,
Thanks for the reply. I tried the workaround as you said before. However unfortunately it did not work.
I attach a capture showing the error and the file that I modified. DataFotos2.txt (142.7 KB)
Thanks,
Diego
Hi, I did another test. I export the file .txt from pix4d and did not chanhe anything in the file. After that I import the same file from pix4d, where say “From File…”, and pix4d show me the same error.
I guess its a software bug,
How can I change all the column altitude?
I have been trying to process a project for some weeks and I always find a different error.
Thanks
The fact that you were not able to re import the file generated by Pix4Dmapper in indeed strange and could indicate a potential issue.
I tried the same (export and then import the file) but was not able to reproduce the issue.
Could you share a project that is causing issues here? A subset of images that give the error would already be enough, there is no need to upload all 1500+ images.
Let me know once the files are available.
