JPEG GPS coordinates are incorrect

Started by Ivan Chevelev, July 29, 2019, 05:32:37 PM

Previous topic - Next topic

Ivan Chevelev

Hello Phil,

I ran into an issue with ExifTool giving me the wrong GPS coordinates when scanning JPEG pictures. The coordinates are close but appear to be off by as much as a whole degree.

With the attached file (8902342294.jpg), I parsed the coordinates by hand using the spec outlined in http://forensicsfromthesausagefactory.blogspot.com/2013/03/location-data-within-jpgs.html and cross-validated it with results from Irfan. And after plotting both sets of coordinates on Google Maps in conjunction with street view I came to the conclusion that ExifTool coordinates are incorrect.

Is this something that you've come across in the past? I also checked with an older version of ExifTool 9.63 and the results match those of ExifTool 11.42.

Here is the bug report data:

  • Windows 10 Pro v1903
  • ExifTool v11.42 (also v9.63)
  • Command: exiftool -a "-gps*" -ee 8902342294.jpg
  • Console Output:

GPS Latitude Ref                : North
GPS Latitude                    : 25 deg 28' 30.00"
GPS Longitude Ref               : East
GPS Longitude                   : 121 deg 39' 21.00"
GPS Altitude Ref                : Above Sea Level
GPS Altitude                    : 82.28588235 m
GPS Time Stamp                  : 09:54:44
GPS Img Direction Ref           : True North
GPS Img Direction               : 96.6372549
GPS Date Stamp                  : 2013:05:31
GPS Altitude                    : 82.2 m Above Sea Level
GPS Date/Time                   : 2013:05:31 09:54:44Z
GPS Latitude                    : 25 deg 28' 30.00" N
GPS Longitude                   : 121 deg 39' 21.00" E
GPS Position                    : 25 deg 28' 30.00" N, 121 deg 39' 21.00" E


Here is what I got with manual parsing:

Offset  Hex Value      Meaning
-------------------------------------------------------------------------
608     4D 4D          TIFF container offset

5444    00 02
        00 04
        00 00 00 06
        00 00 13 54    4948 - Latitude offset relative to TIFF container

5468    00 04
        00 04
        00 00 00 06
        00 00 13 6C    4972 - Longitude offset relative to TIFF container

5556    00 00 00 18    24
        00 00 00 01    / 1
        00 00 14 82    5250
        00 00 00 64    / 100
        00 00 00 00    0
        00 00 00 01    / 1


5580    00 00 00 79    121
        00 00 00 01    / 1
        00 00 08 FD    2301
        00 00 00 64    / 100
        00 00 00 00    0
        00 00 00 01    / 1


And here is the matching Irfan output:

Filename           - 8902342294.jpg
GPS information:   -
GPSLatitudeRef     - N
GPSLatitude        - 24  52.5  0 (24.875000)
GPSLongitudeRef    - E
GPSLongitude       - 121  23.01  0 (121.383500)
GPSAltitudeRef     - Sea level
GPSAltitude        - 82.29 m
GPSTimeStamp       - 9  54  44
GPSImgDirectionRef - True direction
GPSImgDirection    - 96.637253
GPSDateStamp       - 2013:05:31


Let me know if there is anything else I can do on my side to help.

Thank you for the great tool and your continued support!
Ivan

I can's seem to upload the attachment... it's 2.3MB. I'll have to submit it via email.

Phil Harvey

Hi Ivan,

You can email the sample to me: philharvey66 at gmail.com

When I set the GPSLatitude exactly as you say, I get this output:

exiftool -config "" a.jpg -gpslatitude
GPS Latitude                    : 24 deg 52' 30.00"


Here is an excerpt from the -v3 output, with the GPSLatitude value set just as you mentioned, byte-for-byte:

  | | 1)  GPSLatitude = 24 52.5 0 (24/1 5250/100 0/1)
  | |     - Tag 0x0002 (24 bytes, rational64u[3]):
  | |         0084: 00 00 00 18 00 00 00 01 00 00 14 82 00 00 00 64 [...............d]
  | |         0094: 00 00 00 00 00 00 00 01                         [........]


I'm running ExifTool 11.59 on MacOS, but I couldn't imagine the results would be different on Windows.

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

Phil Harvey

Ah.  I've figured it out.  ExifTool is correct.  It is odd that IrfanView gets this wrong.

From this dump you posted:

5444    00 02
        00 04
        00 00 00 06
        00 00 13 54    4948 - Latitude offset relative to TIFF container


I can see that the format is 04 (ie. TIFF LONG), but it should be 05 (ie. TIFF RATIONAL).  When decoded using the indicated format (04), you get the value that ExifTool reports.

Try running this command on the file:

exiftool -validate -warning -a 8902342294.jpg

You should see these warnings:

Warning                         : Non-standard format (int32u) for GPS 0x0002 GPSLatitude
Warning                         : Non-standard count (6) for GPS 0x0002 GPSLatitude
Warning                         : Non-standard format (int32u) for GPS 0x0004 GPSLongitude
Warning                         : Non-standard count (6) for GPS 0x0004 GPSLongitude


What software produced this JPG file?  You should submit a bug report.

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

Ivan Chevelev

Thanks for the quick follow up Phil,

I don't know what software generated these. But based on the metadata for the first picture, it looks like it was just taken with an iPhone 4.
Tested GPS extraction with ImageMagick and it also pulled out the coordinates as if they were in TIFF RATIONAL (05) format same as Irfan.

I don't know if GPS is ever written in TIFF LONG (04). Maybe all other tools just ignore that byte and always treat the 24 bytes as rational?

Will do more testing to see how many cross-tool discrepancies I can find with my data set.

I'll keep you posted,
Ivan

Phil Harvey

Hi Ivan,

I have a number of iPhone 4 samples with GPS, and  none of them have this problem.

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

Ivan Chevelev

Hi Phil, so yes, it looks like just that one dataset had the bad HEX (04 vs 05). It's something we found on the internet from 2012 and it looks like the coordinates have been injected with some unknown software. So that lines up with your theory of that particular software having a bug.

Thanks for your support.
Ivan