GPS data losing accuracy

Bug #1068012 reported by Jim Easterbrook on 2012-10-18
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
pyexiv2
Medium
Unassigned

Bug Description

I have image files with GPS info that has a precision of fractions of a minute. (The files were generated by Microsoft Pro Photo Tools, if that's relevant.)

exiv2 can read these files OK - for example:

exiv2 -g Xmp.exif.GPSLatitude -g Xmp.exif.GPSLongitude -g Exif.GPSInfo.GPSLatitude -g Exif.GPSInfo.GPSLongitude ~/Pictures/chateau_gontier.jpg
Error: Directory Canon with 6144 entries considered invalid; not read.
Exif.GPSInfo.GPSLatitude Rational 3 47deg 49' 35.419"
Exif.GPSInfo.GPSLongitude Rational 3 0deg 42' 25.135"
Xmp.exif.GPSLatitude XmpText 13 47,49.590323N
Xmp.exif.GPSLongitude XmpText 12 0,42.418921W

Reading the same file with pyexiv2 returns the Xmp keys as pyexiv2.utils.GPSCoordinate values with integer attributes: 47, 49, 35 and 0, 42, 25.

As I should have mentioned in question #211407 (which relates to bug #1067894) pyexiv2 returns the Exif keys as three rationals: [Fraction(47, 1), Fraction(49, 1), Fraction(22137, 625)] and [Fraction(0, 1), Fraction(42, 1), Fraction(31419, 1250)].

description: updated
description: updated
Olivier Tilloy (osomon) wrote :

Thanks for the report Jim. Any chance you can attach a sample picture with similar GPS data, so I can easily reproduce and investigate?

Here's a small image of mine, stripped of metadata, then geotagged in Pro Photo Tools. Curiously the latitude and longitude lists of rationals now have seconds set to zero: [Fraction(47, 1), Fraction(2479543, 50000), Fraction(0, 1)] and [Fraction(0, 1), Fraction(1060489, 25000), Fraction(0, 1)]

Olivier Tilloy (osomon) wrote :

The issue is with the GPSCoordinate class (http://tilloy.net/dev/pyexiv2/api.html#pyexiv2.utils.GPSCoordinate) implementation in pyexiv2: it casts the 'seconds' attribute to an integer, assuming seconds cannot be floating point values.

Changed in pyexiv2:
importance: Undecided → Medium
status: New → Confirmed

Given that degrees, minutes and seconds are all stored as 'rational' type in EXIF, I suggest that none of them should ever forced to be an integer. A side effect of this is that the a latitude or longitude value can be represented in many different ways, which will make the == operator interesting to code.

For example, 51 degrees, 30 minutes, 10.25 seconds could be stored as [Fraction(51, 1), Fraction(30, 1), Fraction(41, 4)] or [Fraction(51, 1), Fraction(7241, 240), Fraction(0, 1)]. The GPSCoordinate forms of these could be GPSCoordinate(51, 30, 10.25, 'N') or GPSCoordinate(51, 30.17083333, 0, 'N').

It appears that both forms are used, even by the same software (see my Pro Photo Tools examples). I don't know if there is any good reason not to normalise all to integer degrees & minutes and float seconds. (As long as the constructor accepts floats for all.)

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers