@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