Why more accuracy from OSX's "Preview" application? about exif-py HOT 8 CLOSED

Good question. I have to admit I'm not sure why that is...

I thought maybe it was using XMP information, but the file has none:

> ~/work/oss/exif-py/EXIF.py -dc 0c824ff0-aef6-11e4-8966-5aeb5f0dfc7f.JPG
....
DEBUG XMP not in Exif, searching file for XMP info ...
DEBUG XMP Finished searching for info
....

I then checked with the popular exif tool and got the same result as with this library:

> exif 0c824ff0-aef6-11e4-8966-5aeb5f0dfc7f.JPG
EXIF tags in '0c824ff0-aef6-11e4-8966-5aeb5f0dfc7f.JPG' ('Motorola' byte order):
.....
Latitude            |31, 27, 21,47
....

from exif-py.

Hmm... anything else I can do to help figure this out? Would more photos help?

from exif-py.

What could be interesting is to compare an image not taken with Apple hardware and see if there is the same discrepency.

Maybe there is some sort of proprietary info not present in the Exif?

from exif-py.

Perhaps Preview is reading the same coordinate values, converting to decimal for internal manipulation, then converting back to DMS for the info panel display? That, along with some rounding and false precision might account for the discrepancy.

from exif-py.

Good point. For all we know, OSX's Preview could be the one reporting a wrong value.

from exif-py.

It appeared to be more accurate for the photos I tested it with.

from exif-py.

The difference is 0.002", which is roughly 50cm.
But the best GPS receptors' accuracy is about 3 to 5 meters, which translates to 0.01" to 0.02".
So whatever the different software say, one thing is true for sure: the GPS receptor only provided at best 2-digit precision, so OSX Preview is wrong to display more than that.

Now, where it gets them from? My bet is it computes the latitude using decimal latitude. That is, it internally converts [31, 27, 2147/100] into a decimal number such as 31.45596388888889. This is a very common thing to do, as having just one number for latitude is much more convenient than having an array of 4 numbers.

The problem is, such numbers cannot be perfectly represented as decimals, let alone as floats. So, you just get an approximation. For instance, the closest number to 31.455963888888889 that can be actually represented using a float is 31.455963134765625. You can test that yourself by writing a short C program.

Because of this, when converting the value back into DMS for display, you will not get the original value back, just something close to it. For instance, 31° 27' 21.46839230493.

You then round it for display. Round it to 2 digits, you get 21.47. Round it to 4 digits, you get 21.4684, of which the last 2 digits actually are meaningless garbage.
=> Round it to 3 digits and you get 21.468, that is 21.47 with a -0.002 error caused by conversion approximations.

I might be wrong. Maybe Apple somehow reinvented GPS without telling anyone and is storing extra information in some hidden place in the image. But it seems much more plausible the difference you see means nothing more than "OSX Preview internally uses floats to manipulate the latitude".

from exif-py.

Seems logical, I think we can close this one now. Thanks all.

from exif-py.