The Mysterious Case of why Photos and Preview couldn't see the GPS data embedded in the EXIF of my JPEGs

This is a tale of two photos, both, in theory, with location data embedded in their EXIF metadata, but with the manifestation of that EXIF data to the Apple Photos and Preview apps only available from one.

The First Photo

The first photo, of sunrise on Prince Street, is one that I took in January 2018 on my Nextbit Robin phone. When I run exiftool on this image, I can see the GPS data:

GPS Latitude                    : 46 deg 14' 8.93" N
GPS Longitude                   : 63 deg 7' 26.80" W
GPS Position                    : 46 deg 14' 8.93" N, 63 deg 7' 26.80" W

When I load this image into GraphicConverter, I can see the GPS data:

But when I use the Mac Preview app to look at the photo’s EXIF data, I don’t see anything under the “GPS” tab at all:

And, similarly, the location information doesn’t show up when I import the image into Apple Photos:

The Second Photo

The second photo, one I took in 2014 on my Motorola phone, also shows GPS data in exiftool:

GPS Latitude                    : 51 deg 4' 47.92" N
GPS Longitude                   : 114 deg 7' 41.76" W
GPS Position                    : 51 deg 4' 47.92" N, 114 deg 7' 41.76" W

There’s GPS information in GraphicConverter:

But in this case there is also GPS data showing in Preview:

And there’s a location showing in Photos:

What’s the difference?

When I run exiftool with -v3, for extra verbosity, on the first image, I can see more details about how the GPS data is being encoded in the JPEG images.

In the first photo, the latitude is:

  | | 4)  GPSLatitude = 46 14 8.93 (46/1 14/1 893/100)
  | |     - Tag 0x0002 (24 bytes, rational64s[3])

Whereas for the second photo the latitude is expressed as:

  | | 2)  GPSLatitude = 51 4 47.92 (51/1 4/1 4792/100)
  | |     - Tag 0x0002 (24 bytes, rational64u[3])

The latitude format itself, and the tag ID, are the same, but the number format in the non-working photo is rational64s while the number format in the working photo is rational64u.

Further, if I overwrite the latitude tag in the first photo using exiftool like this:

# exiftool  24788827667_69d2141fa6_o.jpg -GPSLatitude="46 14 8.93 (46/1 14/1 893/100)"

Then the latitude changes to rational64u:

  | | 1)  GPSLatitude = 46 14 8.93 (46/1 14/1 893/100)
  | |     - Tag 0x0002 (24 bytes, rational64u[3]):

And once I do this, Preview becomes capable of reading the latitude from the file:

So what’s the difference between rational64u and rational64s?  From here we learn:

• rational64u is an unsigned rational number, which is a pair of 32-bit unsigned integers.
• rational64s is a signed rational number, which is a pair of 32-bit signed integers.

The EXIF standard clearly says that the latitude and longitude values should be unsigned rational values; this makes common sense, as there are, in addition to the GPSLatitude and GPSLongitude values, also GPSLatitudeRef (N or S) and GPSLongitudeRef (E or W) values which obviate the need for the values to be signed.

So it would appear that while other tools–Flickr, Google Photos, exiftool, GraphicConverter–can read latitude and longitude values expressed, contrary to the standard, as rational64s, Apple tools cannot.

I took a look at a cross-section of my Flickr photos, recently repatriated to my local machine: of 13,542 photos I sampled, 6,612 photos had location data in them according to exiftool; of those, 2,572 photos (mis-)encoded the latitude as a rational64s and 4,040 encoded the latitude as a rational64u.

Of the photos with the latitude expressed as rational64s, 2,271 (88%) were from my Nextbit Robin Android phone; interestingly, there are also 377 photos where the latitude from a Nextbit Robin photo is (properly) rational64u, so I wonder if something changed in the EXIF-encoding library on the device at some point.

How to fix this?

The exiftool utility cannot only read EXIF from files, but, as witnessed above, it can also write EXIF data into files. So I wrote a shell script, fixlocation.sh, to do this:

#!/bin/bash

LATITUDE=`exiftool -s3 -c "%+.6f" -GPSLatitude $1`
LONGITUDE=`exiftool -s3 -c "%+.6f" -GPSLongitude $1`

exiftool -overwrite_original -GPSLatitude=$LATITUDE -GPSLongitude=$LONGITUDE $1

 I can run this on a directory of “broken” images with:

find ./ -name "*.jpg" -exec fixlocation.sh {} \;

The result is files that Apple applications like Preview and Photos can properly interpret the locations of (while not compromising the ability of other applications to do the same).