ExifTool Forum

I'm experimenting with geotagging including orientation information using exiftool 8.76 and can't seem to get exiftool to add the heading, pitch, roll tags.
The plan is to use an android app to log lat, long, heading, pitch and roll data so I'm doing some tests to see how to structure the data from the app.

It seems logical to use a similar format to the Solmeta Geotagger Pro, especially as exiftool now supports PTNTHPR sentences.
I've copied the log data below from someone else's post and modified the time and date to match the test photo I'm working with.

solmetastyletest.log looks like this:

$GPRMC,121352.01,A,3342.0580,S,15105.1157,E,0.04,210.87,150711,,,A*7F
$PTNTHPR,265.2,N,-7.5,N,0.0,N,A*56

I've saved .ExifTool_config file in my home directory which should add the GPSPitch and GPSRoll exif tags. It's pretty much the same as the exiftool example config and seems to load as I can manually add GPSPitch using:
$ exiftool -GPSPitch=35 IMG_3562.JPG

Then in terminal typing the following:
$ exiftool -geotag solmetastyletest.log IMG_3692.JPG
returns:
"1 image files updated"
Ok so far.
Then typing:
$ exiftool IMG_3692
gives this GPS info:
GPS Version ID                  : 2.3.0.0
GPS Latitude Ref                : South
GPS Latitude                    : 33.700967
GPS Longitude Ref               : East
GPS Longitude                   : 151.085262
GPS Time Stamp                  : 12:13:52
GPS Date Stamp                  : 2011:07:15

GPS Date/Time                   : 2011:07:15 12:13:52Z
GPS Latitude                    : 33.700967 S
GPS Longitude                   : 151.085262 E
GPS Position                    : 33.700967 S, 151.085262 E

So standard GPS info is added successfully but not the heading, pitch and roll.

Have I missed something out/failed to change something important in the PTNTHPR sentence?

Do I need more entries to the log file?

I've had a good google but there isn't much info on adding heading, pitch and roll using exiftool as it's such a new feature.

Any pointers really appreciated.

Thanks
Dave

Hi Dave,

Interesting.  I can't see how you can add the GPSPitch but you can't read it back again.

Could you post the output from this command?:

exiftool -v2 -GPSPitch=35 IMG_3562.JPG

Then try this command afterward:

exiftool -GPSPitch IMG_3562.JPG

Also, it may be useful if you could send me the GPS log and image file so I can test it here (philharvey66 at gmail.com).

- Phil

Hi Phil

Sorry I think made the last post a little confusing. To test that the config file was being read I manually added GPSPitch to one photo and could successfully read it.

However when I tried to use -geotag to automatically add GPSPitch to another photo it didn't read the PTNTHPR sentence and apply the GPSPitch or GPSRoll tags.

The log file just contains the two lines I posted previously, I'll email it over with the image.

Commands and outputs you asked for:

exiftool -v2 -GPSPitch=35 IMG_3692.JPG
Writing XMP-exif:GPSPitch if tag exists
Writing GPS:GPSPitch
======== IMG_3692.JPG
Rewriting IMG_3692.JPG...
  Editing tags in: APP0 APP1 GPS IFD0 JFIF XMP
  Creating tags in: APP1 GPS IFD0
JPEG APP1 (24862 bytes):
  Rewriting IFD0
  ExifByteOrder = II
  Rewriting ExifIFD
  Rewriting MakerNoteCanon
  Rewriting CanonCameraSettings
  Rewriting CanonFocalLength
  Rewriting CanonShotInfo
  Rewriting CanonCameraInfo550D
  Rewriting CanonFileInfo
  Rewriting CropInfo
  Rewriting CustomFunctions2
  Rewriting CanonCustom2
  Rewriting ProcessingInfo
  Rewriting MeasuredColor
  Rewriting ColorData4
  Rewriting VignettingCorr
  Rewriting VignettingCorr2
  Rewriting LightingOpt
  Rewriting LensInfo
  Rewriting InteropIFD
  Rewriting GPS
    + GPS:GPSPitch = '35'
  Rewriting IFD0
JPEG DQT (130 bytes):
JPEG SOF0:
JPEG DHT (416 bytes):
JPEG SOS
    1 image files updated


and

exiftool -GPSPitch IMG_3562.JPG
GPS Pitch                       : 35


Thanks a lot for your help.

Thanks for the files.  This looks like a bug in ExifTool.  I'll get back to you when I have a solution, but it is likely that it will require a new release to fix this.  I am currently planning a release for Saturday.

- Phil

OK.  I found the problem and have implemented a fix.  I'll see about bumping up the release to tomorrow instead of Saturday for you.

Thank you very much for reporting this bug.  I'm embarrassed to say that I think this feature never worked properly because it looks like I broke it with an edit to the code just after I did all of my testing.  I hadn't added a test of this feature to the standard test suite , so I missed this problem when I did my release.  I'll see about adding a test for this to the test suite too.

- Phil

Cheers Phil, I'll test it with the next release..

Phil, up till now I had tested the Heading Pitch and Roll data using previous (small) data sets and all had worked well ......  :)
Yesterday, was the first live shoot where I was intending to use the data straight from the camera and log files ....... nothing from the $PTNTHPR sentences came out on the first few attempts using the the -geotag option  :o
So I cut down the file to just the records needed and all worked OK ....  ;D
After a few further attempts it appears that the NMEA sentence order is of importance, in the files that do work they all start;
$GPRMC,135249.000,A,5051.3701,N,00035.6736,E,0.18,6.89,200212,,,A*6D
$PTNTHPR,114.7,N,0.4,N,-5.6,N,A*3C
$GPGGA,135255.000,5051.3701,N,00035.6737,E,1,07,1.4,6.7,M,47.0,M,,0000*5E
$GPRMC,135254.000,A,5051.3701,N,00035.6737,E,0.08,353.06,200212,,,A*65
$PTNTHPR,108.4,N,0.9,N,-3.0,N,A*3F
$GPGGA,135300.000,5051.3702,N,00035.6737,E,1,07,1.4,6.5,M,47.0,M,,0000*5E

However it seems if the file starts with a $GPGGA;
$GPGGA,134437.006,5051.2651,N,00035.7633,E,1,05,4.2,-35.3,M,47.0,M,,0000*42
$GPRMC,134437.006,A,5051.2651,N,00035.7633,E,0.22,155.52,200212,,,A*6D
$PTNTHPR,245.1,N,-88.2,N,74.3,N,A*39
$GPGGA,134442.000,5051.2725,N,00035.7617,E,1,05,4.2,-24.0,M,47.0,M,,0000*41
$GPRMC,134441.000,A,5051.2719,N,00035.7618,E,0.07,81.61,200212,,,A*51
$PTNTHPR,240.2,N,-82.7,N,74.6,N,A*35

Then whilst the normal GPS fields are picked up OK, the $PTNTHPR sentences seem to be ignored, is this expected behaviour ?
I have also noticed that within the NMEA files (from a Solmeta Pro GPS unit) sometimes sentence types appear to repeat so two $GPRMC records follow each other etc. or possibly another sentence has not been recorded I've not spotted this causing a problem, but given the problem above I wonder if this might also cause problems ?  Example below;
$GPRMC,134736.000,A,5051.3277,N,00035.7674,E,2.11,26.24,200212,,,D*58
$PTNTHPR,305.5,N,-35.8,N,-2.8,N,A*23
$GPGGA,134741.000,5051.3304,N,00035.7697,E,1,09,0.9,7.9,M,47.0,M,,*59
$GPRMC,134741.000,A,5051.3304,N,00035.7697,E,2.03,36.67,200212,,,D*55
$GPRMC,134746.000,A,5051.3327,N,00035.7721,E,2.16,34.29,200212,,,D*53
$PTNTHPR,53.8,N,61.3,N,-19.3,N,A*09
$GPGGA,134751.000,5051.3355,N,00035.7733,E,1,09,0.9,10.6,M,47.0,M,,*6A
$GPRMC,134751.000,A,5051.3355,N,00035.7733,E,2.27,19.75,200212,,,D*57
$PTNTHPR,40.3,N,64.4,N,-9.1,N,A*31
$GPGGA,134756.000,5051.3379,N,00035.7761,E,1,09,0.9,11.7,M,47.0,M,,*64
$GPRMC,134756.000,A,5051.3379,N,00035.7761,E,2.03,34.04,200212,,,D*56
$PTNTHPR,54.3,N,51.5,N,-2.9,N,A*30
$GPGGA,134801.000,5051.3401,N,00035.7782,E,1,09,0.9,12.7,M,47.0,M,,*6F
$GPRMC,134801.000,A,5051.3401,N,00035.7782,E,1.83,34.26,200212,,,D*55
$PTNTHPR,48.3,N,36.3,N,23.9,N,A*24
$GPGGA,134806.000,5051.3424,N,00035.7800,E,1,09,0.9,13.1,M,47.0,M,,*6D
$GPRMC,134806.000,A,5051.3424,N,00035.7800,E,2.11,53.56,200212,,,D*5E
$PTNTHPR,25.2,N,77.7,N,7.2,N,A*11
$GPGGA,134811.000,5051.3442,N,00035.7848,E,1,09,0.9,13.3,M,47.0,M,,*65
$GPRMC,134811.000,A,5051.3442,N,00035.7848,E,2.54,60.19,200212,,,D*5E
$PTNTHPR,43.3,N,69.5,N,5.7,N,A*19
$GPGGA,134816.000,5051.3454,N,00035.7895,E,1,09,0.9,12.8,M,47.0,M,,*6F
$GPRMC,134816.000,A,5051.3454,N,00035.7895,E,2.44,70.63,200212,,,D*53
$GPGGA,134821.000,5051.3473,N,00035.7921,E,1,10,0.9,13.5,M,47.0,M,,*64
$GPRMC,134821.000,A,5051.3473,N,00035.7921,E,1.90,12.18,200212,,,D*5E
$PTNTHPR,39.5,N,57.8,N,-6.8,N,A*33
$GPGGA,134826.000,5051.3496,N,00035.7924,E,1,09,0.9,15.8,M,47.0,M,,*6E
$GPRMC,134826.000,A,5051.3496,N,00035.7924,E,1.96,9.63,200212,,,D*67
$PTNTHPR,18.3,N,58.8,N,17.5,N,A*2A
$GPGGA,134831.000,5051.3517,N,00035.7938,E,1,09,0.9,19.6,M,47.0,M,,*6F
$GPRMC,134831.000,A,5051.3517,N,00035.7938,E,1.91,351.89,200212,,,D*69
$PTNTHPR,27.3,N,56.0,N,-5.3,N,A*38
$GPGGA,134836.000,5051.3546,N,00035.7933,E,1,09,0.9,21.9,M,47.0,M,,*63
$GPRMC,134836.000,A,5051.3546,N,00035.7933,E,2.10,353.38,200212,,,D*63
$PTNTHPR,358.3,N,71.1,N,17.3,N,A*1B
$GPGGA,134841.000,5051.3578,N,00035.7931,E,1,09,0.9,22.8,M,47.0,M,,*6E
$GPRMC,134841.000,A,5051.3578,N,00035.7931,E,1.89,4.77,200212,,,D*65
$GPGGA,134846.000,5051.3607,N,00035.7940,E,1,09,0.9,23.0,M,47.0,M,,*6D


Hi Geoff,

What version of ExifTool are you using?  There were problems like this that were fixed in version 8.77.

But the order is important.  Since there is no "end of fix" mark in NMEA, ExifTool assumes that the starts with the first sentence containing a timestamp, and ends when it encounters this same sentence again.  If there are missing PTNTHPR sentences it will cause missing orientation information to be missing for some fixes.

I tried your first 2 examples, and exiftool loads the orientation information properly.  Use the -v4 option to see the information that ExifTool extracts for each fix.

- Phil

OK I'm using 8.79, I'll run some checks with a higher debug level and see what gives.  Thank for the fast response!

Hi Geoff,

In case it helps, here is an example console output from a test using your 2nd log file example.  It should work on any image since I set the geotime manually:

> exiftool -geotag t2.log -v4 -geotime="2012:02:20 13:44:40Z" a.jpg
Loaded 1 points from GPS track log file 't2.log'
Ignored 2 points due to GeoMaxHDOP cut
  GPS track start: 2012:02:20 13:44:41 UTC
    2012:02:20 13:44:41 UTC - dir=240.2 first=1 isDate=1 lat=50.8545316666667 lon=0.59603 pitch=-82.7 roll=74.6 speed=0.07 track=81.61
  GPS track end:   2012:02:20 13:44:41 UTC
Writing File:Geotag
  Geotime value:   2012:02:20 13:44:40 UTC
Writing MIE-GPS:GPSLatitude
Writing XMP-exif:GPSLatitude if tag exists
Writing GPS:GPSLatitude
Writing MIE-GPS:GPSLongitude
Writing XMP-exif:GPSLongitude if tag exists
Writing GPS:GPSLongitude
Deleting MIE-GPS:GPSAltitude
Deleting XMP-exif:GPSAltitude
Deleting GPS:GPSAltitude
Deleting XMP-exif:GPSAltitudeRef
Deleting GPS:GPSAltitudeRef
Writing MIE-GPS:GPSTrack
Writing XMP-exif:GPSTrack if tag exists
Writing GPS:GPSTrack
Writing XMP-exif:GPSTrackRef if tag exists
Writing GPS:GPSTrackRef
Writing MIE-GPS:GPSSpeed
Writing XMP-exif:GPSSpeed if tag exists
Writing GPS:GPSSpeed
Writing XMP-exif:GPSSpeedRef if tag exists
Writing GPS:GPSSpeedRef
Writing XMP-exif:GPSImgDirection if tag exists
Writing GPS:GPSImgDirection
Writing XMP-exif:GPSImgDirectionRef if tag exists
Writing GPS:GPSImgDirectionRef
Writing XMP-exif:GPSPitch if tag exists
Writing GPS:GPSPitch
Writing XMP-exif:GPSRoll if tag exists
Writing GPS:GPSRoll
Writing GPS:GPSLatitudeRef
Writing GPS:GPSLongitudeRef
Writing GPS:GPSDateStamp
Writing GPS:GPSTimeStamp
Writing XMP-exif:GPSDateTime if tag exists
======== a.jpg
Rewriting a.jpg...
  Editing tags in: APP0 APP1 File GPS IFD0 JFIF MIE-GPS XMP
  Creating tags in: APP1 File GPS IFD0 MIE-GPS
Creating APP1:
  Creating IFD0
  ExifByteOrder = MM
    + IFD0:XResolution = '72' (mandatory)
    + IFD0:YResolution = '72' (mandatory)
    + IFD0:ResolutionUnit = '2' (mandatory)
    + IFD0:YCbCrPositioning = '1' (mandatory)
  Creating GPS
    + GPS:GPSVersionID = '2 3 0 0' (mandatory)
    + GPS:GPSLatitudeRef = 'N'
    + GPS:GPSLatitude = '50 51 16.3139999999994'
    + GPS:GPSLongitudeRef = 'E'
    + GPS:GPSLongitude = '0 35 45.7080000000001'
    + GPS:GPSTimeStamp = '13 44 40'
    + GPS:GPSSpeedRef = 'N'
    + GPS:GPSSpeed = '0.07'
    + GPS:GPSTrackRef = 'T'
    + GPS:GPSTrack = '81.61'
    + GPS:GPSImgDirectionRef = 'T'
    + GPS:GPSImgDirection = '240.2'
    + GPS:GPSDateStamp = '2012:02:20'
    + GPS:GPSPitch = '-82.7'
    + GPS:GPSRoll = '74.6'
JPEG DQT (65 bytes):
JPEG DQT (65 bytes):
JPEG SOF0:
JPEG DHT (29 bytes):
JPEG DHT (179 bytes):
JPEG DHT (29 bytes):
JPEG DHT (179 bytes):
JPEG SOS
    1 image files updated

Remember that you need the custom tags defined in your config file to be able to write GPSPitch and GPSRoll.

- Phil

Hi Phil, OK your results noted attached is a zip'ed set of files I used with the Solmeta-xxx.nmea as downloaded complete (starts with $GPGGA sentence), and then with records pruned off from the start, the results of running;
exiftool -v4 -geosync=-16 -geotag *.nmea dsc_0506.nef
the resulting console log file 0506-v4-GPGGA.txt
removing the first  $GPGGA record so .nmea file starts with $GPRMC sentence, results in 0506-v4-GPRMC.txt
and finally removing the first $GPRMC sentence .nmea file starts with $PTNTHPR sentence results in 0506-v4-PTNTHPR.txt
as you will see when the file starts with a GPGGA record no $PTNTHPR sentence data is written, when it starts with anything else it works as expected ... ?
What am I missing ?

Wow, what a mess.

1) The NMEA is not in sequence.  The time jumps backward by 1 second between the GPGGA and GPRMC sentences.  The ExifTool logic  assumeshat the sentences are always in the correct temporal sequence (and in fact, that the GPGGA and GPRMC should both correspond to the same time fix).

2) The PTNTHPR sentence is sometimes missing, and sometimes corrupted.  The corrupted ones will cause problems because ExifTool doesn't currently test the checksums.

My suggestion is to do some pre-processing of the NMEA log:

a) Remove the GPGGA sentences entirely (you will only lose the altitude information)

b) Remove any corrupted PTNTHPR sentences.

c) Remove any GPRMC which is followed by anything other than a PTNTHPR.

But if the altitude is a problem, then this solution isn't optimal.  Also, the pre-processing isn't optimal.  I'll think about this to see if there is anything I can do to improve this for future versions, but for now you would be stuck doing some pre-processing.

- Phil

OK.  I've figured out a way to handle missing and out-of-sequence NMEA information like this.

I still need to do some work before I can say for sure, but I think I should be able to include this improvement in the next release (ExifTool 8.80).

I'll let you know how it goes.

Thanks for this report, and for the sample NMEA file.

- Phil

Hi Phil, Yes its not that nice is it :-( asking around there are some suggestions as to why, like;
Time to process different sentences when EGNOS/WAAS/MSAS is used,
Pushing data onto a stack before Pulling it off and hence in reverse time order etc.
Trouble is without knowing the underlying code its difficult to be sure of the cause. 
As not all sentences contain timestamps its not as simple either as simply resorting it either !

Hi Geoff,

I've got a solution implemented now.  I just need to do some more testing, but it looks good so far.  If all goes well, I'll release 8.80 this weekend with this update.

Supporting the yaw/pitch/roll is turning out to be more work than I had anticipated. :P  However, on the plus side, the NMEA reader should be more robust now for anyone else with erratic NMEA like this.

- Phil

Version 8.80 is now available.

- Phil

Hi Phil,  Your work really is appreciated  :)
I've done some more testing, I started with logging set for every 10seconds on the Solmeta device, very few records were in the wrong order.
Changing the logging to every 5 seconds, and you've seen the results already in the previous attachment.
Next step is every second, ideally that is the setting I would like as unlike actual GPS data the Compass/Pitch/Roll data can vary very rapidly, typically I take 8 shots inside 25 seconds to capture the complete 360 degree panorama, and ideally the three parameters need to reflect the actual orientation and not some estimate calculated between GPS data sets at 10 or 5 second intervals, however there is also the small matter of memory constraints to take into account as well on the logger  :-[  However I can see these limitations being overcome in the not too distant future, as the cost of GPS chipsets and electronic compasses falls low enouth to be incorporated into much cheaper point and shoot cameras!
You can see the final results here for instance http://www.360cities.net/search/@author-geoff_mather/

Hi Geoff,

You've got some very nice pictures there.

For this application you would need very accurate orientation information, which you won't get via ExifTool if your orientation is changing quickly.   As you may know, ExifTool does a simple linear interpolation between nearest adjacent readings.

There is also a possible systematic error due to the inadequacies of the NMEA format (which sucks as a file format for the reason I have already mentioned). Since the PTNTHPR doesn't have a timestamp, one must associate it with the timestamp from another NMEA sentence.  ExifTool will associate it with the nearest earlier sentence with a timestamp, but if you are unlucky with the timing and the PTNTHPR is emitted just before the timestamped sentence, then it will be wrong by the time difference between adjacent timestamps.  If there is always a fixed relationship between the PTNTHPR and the timestamps, it would be possible to compensate for this, but in the general case the only foolproof way to avoid this problem is to hold the camera stead for a time equal to the separation of the timestamps both before and after taking the picture.  This would also nullify any approximations due to the linear interpolation.  However, I realize this is something that may not be practical in real life situations.

- Phil

Hi Phil,  Yes the attitude data is never going to be sufficient to act as a template for perfect image alignment, Control Point alignment will always be needed ! 
However when doing large quantities of shots it always helps to have the individual images in roughly the right position before starting the alignment as otherwise its quite common to get false minimum's in the alignment algorithm.  Especially when doing higher resolution images typically with 3 rows of 10 shots or more, having that attitude data also helps a lot when you aren't able to shoot the normal sequence and there is a missing image or sometimes extra images when distracted.  The other situation is when your not able to use a support (Monopod or tripod) and have to hand hold the camera, then of course the variations are a lot larger  :o

I've just run the 8.8 ver against 120 images and the results are 114 images picked up with adequate data, the remaining 6 all appeared to have no $PTNTHPR sentence within the timeframe so that is as expected.  I'll let you know how I get on with a 1 second data logging run  ;D

Great, glad that things have improved.

When you say "within the timeframe", I just wanted to be sure you knew that this is configurable with the GeoMaxIntSecs setting.  See the geotagging options (https://exiftool.org/geotag.html#Options) for details.  However, for your purposes the default of 1800 seconds (30 minutes) is probably already too long provide a useful orientation.  But I mention this just to be sure you know how ExifTool should function, so you can report any other discrepancies you may notice.

- Phil

Updated version works great, thanks Phil!    :D

Just an update to say that logging at one second intervals produces a very clean result, with no missing records in the log files, no out of place records either, if you think a sample would be of any help Phil shout and I'll drop you a sample.
For those interested in using the data for real then I have put together a very quick page on collecting and using the data with ExifTool, to load the data into images and then to pass the images on to other applications which make actual use of it.  See here for the details http://360.g8dhe.net/cameraattitude/cameraattitude.htm

I have been working on ingesting Roll, Pitch, Heading and Altitude values from nmea sentences as well for a slightly different application, and had a question and maybe some cautionary advice concerning this. I have been using v9.03 and it is properly geotagging imagery using the NMEA sentences such as this sample:


$GPRMC,175315.08,A,3854.7060606,N,09439.6914522,W,83.5,346.3,071012,000.0,W*68
$PTNTHPR,105.2815438983,N,-0.4509931075,N,-1.0056073347,N,A*2C
$GPGGA,175315.08,3854.7060606,N,09439.6914522,W,4,06,2.67,1117.984,M,-32.303,M,,0002*24


my question is, is their any way to avoid interpolation of the values, but use the nearest absolute values for the roll, pitch, heading, altitude, lat, and long? I have very precise values tied tightly to the photos, but slight rounding of the time tags such that the interpolation needs to be avoided.

On a related note, I have also been trying to use geosetter to perform this function, but with worse results than exiftool directly. Using geosetter does not successfully import roll and pitch (but it does bring in heading, but altitude is not sequenced properly, unlike exiftool which does bring in altitude correctly.) Geosetter does have the option to "select exactly to found position"  but this leaves out roll and pitch as mentioned above. (I have been careful to make sure I am using the same config file in both geosetter and exiftool executions).

If anyone has some insight about these issues please share, thanks.

Geosetter doesn't use the exiftool -geotag feature, which is why it behaves differently.

I will add a GeoNoInterpolate setting to ExifTool 9.04 to allow you to turn off the interpolation.  There won't be a corresponding command-line option, so you will need to do this in the .ExifTool_config file (https://exiftool.org/config.html).

- Phil

GeoNoInterpolate works great so far, outstanding!
Does the  GeoMaxIntSeconds work normally with GeoNoInterpolate=1? To make sure I get the right solution matched exactly to the right photos, does it make sense to set GeoMaxIntSeconds to 1 sec  (or maybe 2 sec) so that any imperfect matches get flagged?

Great.  Glad to hear.

I should probably document this: GeoMaxIntSecs has no effect when GeoNoInterpolate is enabled because there is no interpolation.  It is GeoMaxExtSecs that governs the behaviour when GeoNoInterpolate is enabled.  It does make sense to set this to a short time for what you are doing.

- Phil

Edit: Actually, I just realized that the new GeoNoInterpolate feature is essentially the same as setting GeoMaxIntSecs to 0.  I should have thought of this before.  The only difference is when multiple tracks are loaded and the time lies between the two tracks.  With only a single track loaded, the behaviour is identical.

Edit2: With a minor change I can disable interpolation between two tracks when GeoMaxIntSecs is 0 and make the behaviour identical to setting GeoNoInterpolate to 1.  I will do this for ExifTool 9.05 and remove the GeoNoInterpolate option with a note about this in the GeoMaxIntSecs documentation.

Their are two effects that ideally could be enabled: 1) interpolation or using exact trackpoint value, and 2) the allowable offset of an image time from the matched trackpoint time.
Using interpolation makes effect 2) above not applicable, but without interpolation, then option 2) becomes an issue, and with only 1 parameter for control, it does not seem that option 2) would be select-able?

For instance, if I have 100 photos that theoretically should match to 100 exact trackpoints, then all is well. But if I have 110 photos with 100 trackpoints and no interpolation, then either the program will either match multiple  photos to a common trackpoint, or else if the allowable time offset is small enough it would reject assigning a location to the photos that are two far offset from the trackpoint. These are the two possible scenarios.
Geosetter seems to implement this functionality pretty well, giving options for both of these situations and allowing the user to tweak them to come up with good output, but geosetter does not handle pitch or roll input and it seems to mis-assign altitudes from NMEA track files.
Also, when I had GeoMaxExtSecs => 1 in the config file along with GeoNoInterpolate => 1, I got an error in loading the config file, when I delimited out the GeoMaxExtSecs, it worked fine.

So in an ideal world, retaining GeoNoInterpolate and simultaneously GeoMaxOffset might be the ideal solution?

Just some observations about functionality to consider.
Thanks again for the outstanding response and tool!

Quote from: flightfollowing on November 04, 2012, 10:11:16 AM
Their are two effects that ideally could be enabled: 1) interpolation or using exact trackpoint value, and 2) the allowable offset of an image time from the matched trackpoint time.
Using interpolation makes effect 2) above not applicable, but without interpolation, then option 2) becomes an issue, and with only 1 parameter for control, it does not seem that option 2) would be select-able?

But there are 2 parameters.  GeoMaxIntSecs and GeoMaxExtSecs.  Note that extrapolations are done by choosing the coordinates of the nearest point unless it is further away than GeoMaxExtSecs.  And that setting GeoMaxIntSecs to 0 causes all geotagging to use this extrapolation logic.

So I think this should do what you want.

Quotewhen I had GeoMaxExtSecs => 1 in the config file along with GeoNoInterpolate => 1, I got an error in loading the config file, when I delimited out the GeoMaxExtSecs, it worked fine.

There should be no problem doing this.  I suspect you forgot the comma at the end of the line or something else wrong with the format of the config file (illegal character somewhere?).

- Phil

Edit:  Here is the documentation as it will appear in version 9.05.  Please let me know if this isn't clear or if it doesn't allow you to do what you want:

    GeoMaxIntSecs
    Maximum interpolation time in seconds for geotagging.  Geotagging is
    treated as an extrapolation if the Geotime value lies between two fixes in
    the same track which are separated by a number of seconds greater than this.
    Otherwise, the coordinates are calculated as a linear interpolation between
    the nearest fixes on either side of the Geotime value.  Set to 0 to disable
    interpolation and use the coordinates of the nearest fix instead (provided
    it is within GeoMaxExtSecs, otherwise geotagging fails).

    GeoMaxExtSecs
    Maximum extrapolation time in seconds for geotagging.  Geotagging fails
    if the Geotime value lies outside a GPS track by a number of seconds greater
    than this.  Otherwise, the coordinates of the nearest fix are taken.