Adding heading, pitch, roll from log file.

[Phil Harvey]

Version 8.80 is now available.

- Phil

[G8DHE]

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/

[Phil Harvey]

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

[G8DHE]

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 

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 

[Phil Harvey]

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 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

[lifeofdave]

Updated version works great, thanks Phil!   

[G8DHE]

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

[flightfollowing]

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:

Code Select Expand


$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.

[Phil Harvey]

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.

- Phil

[flightfollowing]

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?

[Phil Harvey]

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.

[flightfollowing]

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!

[Phil Harvey]

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.

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.

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.