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.
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.
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.
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. www.dpreview.com 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: palentier.blogspot.com
Replies
Mark,
I just got back from the field (archaeology at Tel Dan Israel) and an Israeli friend of mine took some AP shots using a quad copter and gopro type camera. I am a pilot myself and have always wanted to do AP on digs to get some elevated pictures. Unfortunately this year we did not have a total station, and we contracted out for some final top plans at the end of season. I quickly realized that If I combined a multirotor with AP capabilities and GIS type software I could make top plans using my Photoshop skills from vertical photos. Since this is all likely to be out of my own pocket initially I am researching cost effective solutions. Plan
If I had a quad rotor, and a gps camera ( think Canon SX230) could I use Palentier to generate photo maps that I could use to make accurate top plans.
I understand that there is so much more than simple top plans that can be done with UAV photogrammetry and GIS, but for now I want to start with basic needs.
Thanks Tommy
See ftp://aerialrobotics.eu/webbie-palentier/
It works as good as it gets, I think the major issue will be finding out the way for using post-processed jpegs.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.
see
DSC00518.kml
DSC00518.JPG
trace.txt.TRIG2-001.gpx
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.
<north>NaN</north>
<south>NaN</south>
<east>NaN</east>
<west>NaN</west>
userconfig.xml:
<?xml version="1.0" encoding="iso-8859-1"?>
<USER_CONFIG>
<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"/>
</USER_CONFIG>
DSC00518.JPG
trace.txt.TRIG2-001.gpx
DSC00518.kml
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.
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.
Here is the first mostly working copy of the new Palentier.
http://antivverse.isa-geek.net/Palentier-v1.0pre-RC-1.rar
Obviously there is A LOT to get done with it but its coming along.
Please check out the matching. It works to match all of the files you have sent.
I have not made any other changes to actually calculations and such. So hopefully it all works as before.
My remark was, that when loading TWICE the same gpx, the timestamp ending was sometimes 0 sometimes 1 (50% probability).
BTW my best matched palentier is here
www.aerialrobotics.eu/examples/PalentierWinterTest2.kmz
and the most hit-rich is here
www.aerialrobotics.eu/examples/PalentierWinterTest6.kmz
In general the errors when flying at 200m are clearly unacceptable,
unless you want to 'arrange' photos and check the coverage
(this is the best application of Palentier for fixed wing, I think).
In the next few days I should have another testable version for everyone to use.
The Gui is completely redone, some of the processing errors have been fixed (hopefully) and all the data will be editable. There will be more coming for it after this though as I try to make it 'smarter' for matching and such. I have a couple bright ideas for that.
Once I finish with this, comment and clean up the code some I will be posting the source for anyone to download and use.
One comment, the times mentioned below are accurate. All times are in seconds. For every GPX time that is the same it gets incremented by 1 millisecond which does not affect the outcome at all. Most GPS's have 2 entries per second. Thus the 0, and 1. But this allows for other, more accurate entries at a later time.
One more bug:
if you move the Palentier_Beta_v019p0.jar to another directory, and run it, all settings are lost.
Most probably because the actual application path is added to the registry key name when saving those settings.
Quite annoying feature because you can 'lose' settings without knowing it.
OK I have implemented custom offset in my software: +day,+hour,+minute,+second
so it is easier to play with.
General impression:
In Canon S45 the time used by Palentier is somethign not reflecting photo digitization time and teh results are hopeless.
Out of 343 latlon marks in gpx, out of 357 JPEGS loaded, only 157 mapped into positions. As expected, as teh time offset was chosen usting the last few photos, they are in positions. The rest is almost there, but not quite.
I really need more verbose JPEG parsing in such a way I can capture it from Palentier. At the moment even the Java console output is too short to hold all data if opening even 50 jpegs.
Not enough to find a pattern among lost chains.
Stress testing results:
kmz of 157 photos at 600pix res easily reached 87MB as expected, exploding all was left running from GoogleEarth.
Reduced to 320pix resolution and exploded the app again, kmz is 27MB but memory usage more than 1 gigabyte from gogole earth.
Lesson: GE is NOT a GIS database.
Apparently the software is guessing well the camera parameters, but the timing is dubious, probably because Palentier was not used so far for processing long flights or maybe we still have a secret issue in how Canon S45 writes exif.
So retried with 42 photos and there were only 20 matches.
Because of roll stabilised head in Pteryx and with heading estimator, the results 'show potential for improvement',
but could have been much better with working timestamp matching.
FYI
GPICSYNC 1.2 is able to parse jpeg data no problem, no coordinates are lost
PalentierWinterTest.kmz