500' Elevation Variation Recorded for Takeoff from the Same Spot

@Meta4,

Thanks for your comment.

For the P4P, it is not the GPS Altitude that is stored in the Exif info for each image. It is just a copy of the Absolute Altitude entry which is derived from the on-board barometer.

Below is the Exif data for the GPS Altitude and Absolute Altitude from 9 of the 118 pictures in a mission. The other 109 show the same result; the GPS Altitude is a copy of the Absolute Altitude and there is only 10 cm variation in this altitude for 95%+ of the pictures.

I used exiftool by Phil Harvey to extract the data:
C:\Users\Terry>exiftool d:\dcim\100media*09*.jpg -gpsaltitude -absolutealtitude -n
and below is the tail end of it for the last 9 pictures in the 118:
======== d:/dcim/100media/DJI_0991.JPG
GPS Altitude : 248.171
Absolute Altitude : +248.17
======== d:/dcim/100media/DJI_0992.JPG
GPS Altitude : 248.171
Absolute Altitude : +248.17
======== d:/dcim/100media/DJI_0993.JPG
GPS Altitude : 248.171
Absolute Altitude : +248.17
======== d:/dcim/100media/DJI_0994.JPG
GPS Altitude : 248.171
Absolute Altitude : +248.17
======== d:/dcim/100media/DJI_0995.JPG
GPS Altitude : 248.071
Absolute Altitude : +248.07
======== d:/dcim/100media/DJI_0996.JPG
GPS Altitude : 248.071
Absolute Altitude : +248.07
======== d:/dcim/100media/DJI_0997.JPG
GPS Altitude : 248.071
Absolute Altitude : +248.07
======== d:/dcim/100media/DJI_0998.JPG
GPS Altitude : 247.871
Absolute Altitude : +247.87
======== d:/dcim/100media/DJI_0999.JPG
GPS Altitude : 247.971
Absolute Altitude : +247.97
118 image files read

Regards,
Terry.

@Jeremy

I re-did the experiment of combining the same set of pictures only this time they were nearly the same. The only difference is that the second set has a 1 cm offset in the AbsoluteAltitude data. I made this change in order to get DD to read all 286 photos otherwise it would just skip the 143 duplicates even though there were taken from difference directories.

The results are not good. While the 2D map looks visually the same and has no holes like the prior result, the cross-section thru the building (shown below) shows the wrong elevations and measures too long, 191’ vs 176’ actual.

This was a simple experiment, adding the same set of 143 pictures together with a tiny, 1-cm, larger absolute altitude in the second set. Why does this make a substantially worse 2D map with distances off by many feet, both horizontally and vertically?

The two missions are:
Nov3BigFixedElevation for the original mission with 143 photos.
DuplicateSetSameAbsAlt for the case with duplicate pictures (within 1-cm) so 286 photos.

Regards,
Terry.

@Jeremy,

I tried another experiment where I zeroed all the Relative Altitude data. In this case the processing Failed. I have never seen this before so I assume it due to the zeroed data.

So apparently DD needs the Relative Altitude data and accurate Absolute Altitude data (that contains real elevations) to make good Maps which show the correct elevation above sea level when using Measurement Annotations.

Regards,
Terry.
@chasemgray, @Nipul, @zach1

Did you see the example I gave?
The barometer was telling me that my Phantom was at about positive 30 metres but the Exif info shows negative 18 metres. The Exif info altitude did not come from a barometer.
The Phantom has no way to know what the absolute altitude is (except when it is in VPS range).
In the Exif data, it has the GPS altitude and also has the barometer altitude in XMS data.

Meta4,

I need more information. First some background: The Exif data contains fields for the GPS Longitude, GPS Latitude, GPS Altitude, Relative Altitude, Absolute Altitude among others. But these are the ones pertinent to our discussion.

The GPS Longitude and GPS Latitude come from the GPS receiver in the P4P.
The GPS Altitude is a copy of the Absolute Altitude field.
The Relative Altitude = Barometer-based altitude - Barometer-based altitude of takeoff point.
The Absolute Altitude = Barometer-based altitude

To compute the barometer-based altitude the P4P seems to be using the standard equation
p = 29.92 x (1 - 2.25577x10-5 x h)^5.25588 in units of "Hg, where h is the altitude above sea-level in meters.

So which of these 3 (GPS Altitude, Relative Altitude, Absolute Altitude) are you referring to when you say:
The barometer was telling me that my Phantom was at about positive 30 metres but the Exif info shows negative 18 metres.
I need to understand which of these 3 corresponds to barometer and Exif info in your sentence.

Regards,
Terry.

[quote=“SolarBarn, post:25, topic:7617”]
The GPS Altitude is a copy of the Absolute Altitude field.The Relative Altitude = Barometer-based altitude - Barometer-based altitude of takeoff point.The Absolute Altitude = Barometer-based altitude[/quote]
I had always assumed that GPS Altitude meant GPS Altitude.
It’s quite misleading if the GPS Altitude field in exif info is showing data from the barometer.
But that would be more useful that actually providing GPS altitude data which is very unreliable.

It appears that Absolute Altitude as shown in Exif info is quite different from the standard definition of Absolute Altitude used in aviation.

@Meta4,

We share the surprise of what’s actually in the fields of the Exif data.

I have been struggling to get my maps to show proper elevations based upon sea-level. First I changed the GPS Altitude field in the Exif data but DroneDeploy ignored this. Then I changed the Absolute Altitude field and this worked. Now when I click around in my 2D map using Measurement Annotations, I see much more accurate elevations above sea-level.

What is the standard definition of Absolute Altitude? Are you saying its not altitude above sea-level?

Regards,
Terry.

@Jeremy,

I completed a 6th experiment in DroneDeploy. The six experiments, quick summary of results and their mission are:

  1. Original 143 photos processed to generate maps > Maps look good > Nov3BigFixedElevation
  2. Original + Original with same AbsoluteAltitude > Maps look good > SameSame
  3. Original + Original with RelativeAltitude increased by 1 cm > Maps look good > DupRelAlt1cmHigher
  4. Original + Original with AbsAlt increased by 391.47’ in all photos > Maps are bad > TwoSets119mApart
  5. Original + Orig with AbsAlt increased by 1 cm > Measures are bad > DuplicateSetwith2ndSet1cmHigher
  6. Original photos with RelativeAltitude set to 0 in all photos > Process failed; no Maps > ZeroedRelAlt

Here is the variation data from the 5 experiments that generated maps:

The first, second and third experiments make sense. Processing the same pictures twice results in about the same variation in Z and RMSE as does adding the same pictures with only a 1 cm RelativeAltitude increase. Also the fourth experiment makes sense; adding pictures with a 119 m increase in the AbsoluteAltitude is disastrous.

But the fifth experiment is hard to understand; a 1 cm offset in the AbsoluteAltitude of the 2nd set of pictures explodes the Z variation from 1ft up to 2.2ft and exponentially explodes the RMSE from 6.2ft up to 28.2!!! Even more strange is that the X and Y variation see most of this increase, increasing by 4.4X and 17X respectively. Hopefully the DroneDeploy engineering team has an explanation for this bewildering result.

Based upon these experiments, it makes me worry about adding more pictures later on to improve the map quality if the Absolute Altitude data in the photos has any error. Apparently a tiny 1 cm error can throw the results way off, exploding the RMSE by over 4.5X!!!

Your thoughts?

The results of the 6th experiment just confirm that there needs to be data in the RelativeAltitude field of the Exif of the photos in order for DroneDeploy to process the data to create maps.

Regards,
Terry.
@chasemgray, @Nipul, @zach1, @Meta4

[quote=“SolarBarn, post:27, topic:7617”]
What is the standard definition of Absolute Altitude? Are you saying its not altitude above sea-level?[/quote]
In aviation Absolute Altitude is the height of the aircraft above the ground below it.
There is no way for the Phantom to calculate this. It can only give a height above the level of the launch point.

@Meta4,

Agreed. The Relative Altitude field in the Exif data is the altitude above the launch point.

What I have found is that I can correct the AbsoluteAltitude data so that all the elevations come out relative to sea-level. Its sort of an auto-calibration technique. I let DroneDeploy tell me what it thinks is the elevation of the launch point based upon its first processing of the pictures. And then I add an offset to the AbsoluteAltitude data in all of the photos in order to make the launch point elevation be relative to sea-level. The offset = sea-level Elevation of launch point - Elevation of launch point measured in DroneDeploy.

Take, for example, my case where DroneDeploy said the elevation of the launch point was 936 feet. Not surprising since the barometric pressure was high compared to normal by around 0.064" Hg. But I know the launch point is 1000 feet above sea-level. So I added 1000 - 936 = 64 feet to the Absolute Altitude in every photo and had DroneDeploy reprocess the pictures. Now when I click on the launch point in Measurement Annotations, the elevation is shown as 1000 feet.

I wanted to use Exiftool by Phil Harvey to add the 64 feet = 19.5 m offset to the Absolute Altitude in all the photos since it is a one-line command in a Windows Command window (from the old DOS days). But Exiftool changes the format of the XMP inside the Exif data that contains the DJI data for RelativeAltitude and AbsoluteAltitude and more. And then DroneDeploy can no longer parse it. This is because DroneDeploy is not using a proper XMP parser which would recognize the XMP created by Exiftool. So I wrote a Python script to update the AbsoluteAltitude field:

Python Script to change altitude in DJI AbsoluteAltitude field in Exif data of a photo.

from time import time
import System
startime = time()
altitudeOffset = 0.01 # Offset = Actual altitude - altitude measured on DD map
dir = ‘C:\Users\Terry\Pictures\testele3’ # Set this to directory with photos
key = ‘drone-dji:AbsoluteAltitude="+’ # Fixed part of search pattern
files = System.IO.Directory.GetFiles(dir, ‘*.JPG’)
for file in files: # Offset the altitude in all photos
__ f = open(file,‘rb’); s = f.read(); f.close() # Open, binary read file and close
__ i = s.rfind(bytes(key)) + len(key) # Find pointer to value of absolute altitude
__ if i == len(key)-1: # then rfind returned -1 since it did not find key
____ print ‘The key:’, key , ’ was not found in file ‘, file, ‘\nPlease fix and retry’
____ exit()
___ oldAlt = str(s[i:i+10]).split(’"’,1)[0] # 10 works for up 100,000ft; Remove " and beyond
___ original = bytes(key + oldAlt + ‘"’) # Construct byte pattern for search
___ new = float(oldAlt) + altitudeOffset # Add offset to old altitude
___ fixed = bytes(key + ‘{0:.2f}’.format(new) + ‘"’) # Construct replacement bytes
___ s=s.replace(original, fixed, 1) # Search and replace bytes
____ with open(file, ‘wb’) as output_file: # Open file for binary write.
_______ output_file.write(s) # Write byte array to file.
______ print file, oldAlt, ‘{0:.2f}’.format(new) # Write summary of change for each file
print ‘Time = {0:.3f} sec to add altitude offset of {1:.3f} to {2} files.’.format(time()-startime, altitudeOffset, len(files))

Note: I inserted ___ in order to show the structured programming as the Forum deletes out leading spaces.

I run this program inside Rhino because that is the place I already have a Python interpreter. But this code could easily be ported to other Python’s or languages.

So anyway, that’s my story up to now. At least I have a path for fixing the elevation without using GCP’s. And it lets me correct photos added later to improve the map quality. These photos could have been taken when the barometric pressure was significantly different which, as I have recorded in my missions, can move the AbsoluteAltitude data around by 100’s of feet. All this can be done without the use of GCP’s. This methodology can provide very low Z variation but does nothing to reduce X and Y variations, for those you need GCP’s.

Regards,
Terry.
@Jeremy, @chasemgray, @Nipul, @zach1