Palentier: Using UAV Open Source Software to Map with Kites

Palentier is an Open Source software that was originally created by me and a good friend (M. Stange) for processing aerial images from un-manned aerial vehicles (UAVs) like the MikroKopter.  Palentier can process aerial photographs into georeferenced and scaled images which accurately reflect the location and size of objects in the real world.  These images can be exported to Google Earth or to GIS software, like ArcGIS, for review and analysis.


Our current attempt is to modify the software so that it could be useable by the Kite Aerial Photography (KAP) community. Several weeks ago, I asked the KAP forum for help with test images and rig GPS data. They really came through and I now have results from using Palentier with KAP imagery.  The system was tested using data from four places (Northern England, and Northern Libya, Southern Texas, and West Virginia).  All had good results and all but one (West Virginia which I don't have permission to share publicly) are shown here.


Nicholas Kirby provided several dozen images from his KAP work south of Tripoli in Libya.  The building in the photographs is a Roman mausoleum.   Nick provided Qstar GPS data from his location, the kite, and a stationary point (his vehicle).  Primarily the GPS data from the kite was used in Palentier's processing.


Google Earth File (~3.5 Mb)


After days of poor wind, Lindsey Kemp successfully  photographed an area near Eldwick, England.  He used i-gotu GPSes to record locations for both the kite rig and anchor.  Again, the kite's GPS data was the primary locational data used in Palentier.


Google Earth File (~2 Mb)


I used a ground based handheld GPS (Garmin) that I carried on my person, to process this aerial photograph of my crews excavating a burned rock feature near Del Rio, Texas. 


Google Earth File (~1.6 Mb)

I'd like to point out that you can realistically measure things in this image using the measure tool in Google Earth.  The  excavation unit is four meters long north to south.


The fourth project was conducted near Canaan Heights, West Virginia for USGS biogeographers.  They are using KAP and Palentier to map micro-floral plant communities in wetland environments where other means of mapping are too costly or too slow. ( I currently do not have permission to share their images but will post them here in the future if they grant it.)


Lessons Leared:


Camera Parameters

Palentier was originally tested using Canon cameras.  Canon cameras have a very rich EXIF header that  many other manufacture's lack.  When tested on non-Canon cameras, I found that some of the information about the camera's configuration had to be manually added.  To address this, we added new input fields into Palentier's "Options".  The main parameter that is lacking from non-Canon cameras is the metric sensor size. keeps sensor size information for most modern cameras on the "Specifications" section of its website.


Ground Elevation and Altitude Override
For Palentier to work properly, it needs two things: one, the general elevation of the ground being photographed and two, the approximate height of the camera above that ground. To accommodate for this a new "Ground Elevation" option was added to the software.  We have found a glitch in the code that does not allow for the proper manual selection of the elevation.  Until we can fix this, a temporary work around  is to use the "Altitude Override" option and enter the approximate altitude the camera was flown at.


Compass Override and Compass Declination

The test data had only approximate declination information for the camera (which way the top of the camera was point at the time a photograph was taken).  From my own experience this is not unusual because the rig tends to have a lot of play in it as the wind buffets the camera constantly.  To account for this, a "Compass Override" option was created.  Unfortunately, there is a glitch in this code as well, and it does not work properly, yet.  Luckily, the "Compass Declination" option does essentially the same function.  So, this option was used to rotate the images until the approximate north in the photographs matched true north.


Offset North and South

The GPSes used in these tests, (i-gotu GT120, Garmin Map 60Cx, and Qstarz)  are only accurate to between 10 and 15 meters.  This low level of accuracy can throw the image locations off a bit.  To allow the user to "bump" the photographs into place, the "Offset North" and "Offset East" options are used.  The user can export a set of photographs, see that it needs to be moved one direction or another, pick the appropriate options and re-export for proper fit.


General Issues

The biggest issue challenge a user might have with using Palentier and KAP imagery is that it is not fully automatic.  When Palentier is used with MikroKopters or other UAVs, all the data  for geo-location and rectification are automatically generated and the process is as simple as a few clicks of the mouse.  Using Palentier with KAP involves more user input and may require multiple exports to Google Earth as well as fine tuning of parameters in Palentier.  This can be a little cumbersome. Furthermore, since there is lot of variance between individual photographs  taken from a kite, it will often be best for a user to adjust a single image at a time instead of being able to bulk process dozen of images at once.


Palentier does not correct the distortion in photographs.  All photographs have some level of distortion resulting from aberrations in manufacturing and some by design (like fisheye lens).  Distortion is also present in ortho photography when the camera is not pointed straight down.  The nature of KAP (using cheap cameras and wind driven flight) can exaggerate some of these distortion issues problems.  What this means to the user is that it may not be possible to have every portion of a kite aerial image lineup exactly with Google Earth (but it should still be pretty darn close).  Alignment problems can arise when there is great variability in the elevation of the ground (like when photographing the top of a mountain and the valley below).  We compensate for these alignment issues by processing the images in photogrammetry software, such as Leica Photogrammetry Suite, (which Palentier supports export to) but are not currently directly handled by Palentier.


Want to help?

Palentier is Open Source and meant to be an asset we can all take advantage for  fun and in our work. Any thoughts on how to improve the software are always welcome. I am not a very good programmer but I do understand the principals of photogrammetry.  If you are a programmer and interested in further developing the software,  we need your help.


Many Thanks
I am very grateful to Nick Kirby and Lindsey Kemp for sharing their aerial photographs and for taking the time to collect GPS data from their rigs.  You are both awesome and your help is genuinely appreciated.


Thank you!


This posting is also available on my blog:

Views: 4372

Reply to This

Replies to This Discussion

Yes it did.


I have spent several days trying to get an algorithm to work to match. After failing to successfully write a time matched regression algorithm I just did a mutli-pass based on possible tolerant matches and weight of the possible match.


For the data I have this works.


For everything else It will probably have to wait until I get the gui finished so that people will be able to match by hand. I have made no other changes other than the matching so be patient with everything else. I will get another version out later this week for editing data and custom matches.


Download link:

If I do a match, then clear match results, and click match, no matching is done.

have to reload GPX in order to flush matching logic. Very counterintuitive.


I must say the matching logic requires quasi-continuous gpx time space, there are still the same gaps as always.


Anyway. the window title is pre-RC-1 not 2 !!! in the rar above.


Pity the functionality ok making kmz is simply not working, this is a regression (all overlays even when matched sucessfully, have now null entries in the kmz)

As you see, you cannot override focal length in order to provide a replacement for missinf EXIF.

This missing exif can be a result of applying other software like imagemagic for correcting brightness etc.

So it is a pity it cannot be done. An image in attachment.


Krzysztof, We just completely revamped the software. The new release will be public as soon as I find the time to rewrite the manual.

Check your email.  I am sending you the latest jar to test.  It should fix the focal length override issue.


As you see, you cannot override focal length in order to provide a replacement for missinf EXIF.

This missing exif can be a result of applying other software like imagemagic for correcting brightness etc.

So it is a pity it cannot be done. An image in atatchment.



Use secondry gpx entry


Use secondry gpx entry


Sony Webbie case 2009-12-28 (not the one with focal override mentioned recently)

Use attached img and gpx, palentier produces kml/kmz with NaN what freezes google earth.

Despite focal override to 5.8.






Still unable to provide focal length as mentioned in previous post.

The value is accepted but the secondary error perists, see console screenshot.


Suprising effect:

when erasing a text field, instead of seeing 0 there, the wole user interface seems blocked while

there is a silent message in the console window. It is very counter-intuitive, normally I woudl close and application at that point.


Not sure why but Palentier seems to match better, but produces NaN results for all cases

except the 3 long winter passes from canon S45. Otherr S45 cases are not exported OK.



<?xml version="1.0"  encoding="iso-8859-1"?>
<Double Name="altitudeAdjustment" Value="0.0"/>
<Double Name="altitudeOverride" Value="0.0"/>
<Double Name="compass" Value="0.0"/>
<Double Name="compassAdjustment" Value="0.0"/>
<Double Name="compassDeclination" Value="0.0"/>
<Double Name="compassOverride" Value="0.0"/>
<Double Name="declination" Value="0.0"/>
<Double Name="elevationAdjustment" Value="0.0"/>
<Boolean Name="exifData" Value="true"/>
<Double Name="focalLength" Value="0.0"/>
<Int Name="logLength" Value="65536"/>
<Double Name="matchElevation" Value="1.0"/>
<Int Name="matchTime" Value="1"/>
<Int Name="maxkml" Value="160"/>
<Double Name="offsetEast" Value="0.0"/>
<Double Name="offsetNorth" Value="0.0"/>
<Double Name="sensorHeight" Value="0.0"/>
<Double Name="sensorWidth" Value="0.0"/>
<Long Name="timediff" Value="0"/>
<Boolean Name="useSecondaryGPX" Value="false"/>
<Boolean Name="verbose" Value="false"/>


Krzysztof, the issue here is that the file lacks sensor size information. I looked on the Sony website and found that the Webbie sensor is 1/2.5" (5.760 x 4.290 mm) in size.  Enter these values into the sensor override options and it works.

If you perform a match and then click the "+" next to the image name in the "Match GPX and JPG" window, you can see what values Palentier is working with.  This helps spot important missing EXIF data.


Right, thank you, I got a little lost here.

Indeed The trick works for original Webbie files:

focal 5.8 and 5.760 x 4.290 sensor size fixes the issue.

There is a nice result being uploaded to the ftp.

However when using modified jpegs that have the exif data absent, providing those 3 values is not helping, regardless if load exif tickbox is checked or not. An example of such file in attachment.

Can you show me an example of the pre-modified file versus the modified version?
Here they are
One more, this one has same pixel size but similar EXIF issues.

Reply to Discussion



Season Two of the Trust Time Trial (T3) Contest 
A list of all T3 contests is here. The current round, the Vertical Horizontal one, is here

© 2020   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service