• P: Loses precision in exported EXIF GPS coordinate...

P: Loses precision in exported EXIF GPS coordinates

LEGEND ,
Feb 20, 2019 Feb 20, 2019

Copied

[This is fixed in LR 8.3 -- John Ellis]

LR unnecessarily reduces the precision in exported EXIF GPS coordinates to about 18 centimeters.  A trivial one-line fix would increase the precision of exported coordinates to about 0.004 centimeters.

ModernGPS augmentation systems and post-processing can produce coordinates with accuracy at the centimeter level or finer.   For example, this LR user is processingdrone pics for photogrammetry applications: https://forums.adobe.com/message/10936939

Thisbug affects coordinates in exported JPEGs and TIFFs but not in raw XMPsidecars, which maintain high precision.

Workaround

Aworkaround is to use the Run Any Command plugin to create an exportpost-process action that runs ExifTool with arguments that copy the GPScoordinates from the original to the exported file.

Details of the Bug

EXIFrepresents GPS coordinates with three rationals (fractions) for degrees,minutes, and seconds. The numerators and denominators are stored as 32-bitunsigned integers, allowing extremely fine precision (on the order of 1 part in70 million of latitude or longitude seconds).

Forexample, ExifTool stores the latitude 37.1234567891389 in EXIF with these threerationals:

degrees= 37 / 1
minutes= 7 / 1
seconds= 767091 / 31381

LRstores GPS coordinates in the catalog as 64-bit floating point numbers, whichallow 15 decimal digits of precision, with at least 12 fractional digits. Thisprovides a precision of roughly 0.00001 (10^-5) centimeters.

Butinexplicably, LR exports EXIF coordinates using a minutes denominator of only10,000, limiting precision to about 18 centimeters. For example, it exportslatitude 37.1234567891389 as:

degrees= 37 / 1
minutes = 74074 /10000
seconds= 0 / 1

(Youcan examine the rational representation of the exported coordinates using"exiftool -v".)

Thefix is trivial -- use a minutes denominator of 50,000,000 rather than 10,000,which will increase the precision to about 0.004 centimeters.  (A denominator of 50,000,000   is small enough to allow a maximum value of60 to be represented as a 32-bit unsigned rational.)

Here'ssample code of how to do the conversion from floating point to the EXIFrational representation:

`function degreesToEXIF (d)    local sign = d >= 0 and 1 or -1    local degrees, fracDegrees = math.modf (math.abs (d))    local minutes = fracDegrees * 60    local minutesDen = 50e6    local minutesNum = math.floor (minutes * minutesDen + 0.5)    if minutesNum == 60 * minutesDen then        degrees, minutesNum = degrees + 1, 0        end    return sign, degrees, 1, minutesNum, minutesDen, 0, 1    end`
Bug Fixed
TOPICS
macOS, Windows

Views

50

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
21 Replies 21
Community Beginner ,
Feb 21, 2019 Feb 21, 2019

Copied

Thanks, John for reporting this, and the details.

I will be filing this for the engineering team to address, in one of our planned future updates.

Report

Report
LEGEND ,
Feb 21, 2019 Feb 21, 2019

Copied

Thanks.

Report

Report
New Here ,
Mar 04, 2019 Mar 04, 2019

Copied

Hi John, I am trying to do the workaround but I can't seem to get it to work. I have installed the exiftools and the Run any command plugin. Do use the Command per Image or the Command to execute upon completion of all images? What would the command be?
I would be grateful for any help.

Report

Report
LEGEND ,
Mar 04, 2019 Mar 04, 2019

Copied

I'm jammed today but will try to get to this tomorrow.

Report

Report
LEGEND ,
Mar 05, 2019 Mar 05, 2019

Copied

Here's how to configure Run Any Command on Mac to copy the high-precision GPS coordinates from the catalog to the exported file:

The "Command per image" is:
`/usr/local/bin/exiftool -gpslatitude={Latitude} -gpslongitude={Longitude} "{FullExportedFile}"`
Note you'll have to install the free ExifTool also.

The Windows command line is similar -- just use the full path to "exiftool.exe" at the beginning of the command line.

Report

Report
New Here ,
Mar 07, 2019 Mar 07, 2019

Copied

Thanks John for the instructions, but I am still having troubles.  I got the Run any Command script working and ExifTools command  working, but it appears that when the Run any Command/ExifTool fetches the original Lat/Long/Alt coordinates for the image, it's only getting the converted LR coordinates instead of the actual coordinates.  Were you able to get the original coordinates using a Mac? I am using Windows. Could this be my problem?

Report

Report
LEGEND ,
Mar 07, 2019 Mar 07, 2019

Copied

There shouldn't be any difference between Mac and Windows. Why don't you upload a sample photo to Dropbox or similar and post the sharing link here.  That will let me see what might be going wrong.

Report

Report
New Here ,
Mar 07, 2019 Mar 07, 2019

Copied

Here is one of the geotagged images: https://photos.app.goo.gl/sy9Xxm6sBFdpL4rb9
Thanks

Report

Report
LEGEND ,
Mar 07, 2019 Mar 07, 2019

Copied

I was mistaken -- the coordinates stored in the catalog don't match those stored in the file's EXIF.  They're considerably less precise.

For example, if EXIF:GPSLatitude = 46/1 39/1 44037/2000 = 46.65611625, the catalog stores
46.656116666667, a difference of 4.16667E-7, about 5 cm.

I'm wondering if LR's EXIF reader is improperly using 32-bit floats rather than 64-bit floats to read the GPS coordinates.  Hmm...

Regardless, this Run Any Command command line will copy the coordinates directly from the master file into the exported file, preserving all the precision of the master and ignoring what LR has stored in its catalog:
```/usr/local/bin/exiftool -tagsfromfile "{FullMasterFile}" -gpslatitude -gpslongitude "{FullExportedFile}"
```
Note that this only works with masters that are JPEGs and TIFFs, not raws (which may have .xmp sidecars storing their metadata).  To handle raws with sidecars would take a little extra scripting.

Report

Report
New Here ,
Mar 11, 2019 Mar 11, 2019

Copied

Thanks John, that works perfectly. I also added the -gpsaltitude for the altitude
since LR was strangely converting 784.96151731720727 meters to 500 meters:

"C:\Windows\exiftool.exe" -tagsfromfile "{FullMasterFile}" -gpsaltitude -gpslatitude -gpslongitude "{FullExportedFile}"

Report

Report
LEGEND ,
Mar 11, 2019 Mar 11, 2019

Copied

"LR was strangely converting 784.96151731720727 meters to 500 meters"

That is curious.  With the test photo you posted above, my LR preserved on export its altitude of  784.9615173 m.

Can you reproduce that problem with other photos?

Report

Report
New Here ,
Mar 12, 2019 Mar 12, 2019

Copied

I did some testing on some other photos and altitude is not being preserved. I tested three photos from a 733, 734, and 735. All three had incorrect altitude after exporting without using the ExifTool.  I re-exported using the ExifTool and the altitude was preserved but only to  one decimal place unlike the test photo, which had all the decimals after ExifTool.  Also, another odd thing happened, only the longitude was preserved but the latitude was incorrect and not matching the original or un-ExifTool version.  The images were originally shot with raw+jpg so LR show them as combo of DNG/JPG. The DNG stores the metadata internally and does not have a side card file. Both the original DNG and JPG have identical GPS settings in properties. Any idea why only lat is incorrect and alt is only being preserved to one decimal.

Report

Report
LEGEND ,
Mar 12, 2019 Mar 12, 2019

Copied

It's funny to learn that problems like this aren't caught by the test people at ADOBE. I came to the same problem when trying to use a plug-in (Search Replace Transfer from John Beardsworth).
If you copy the information from the LR GPS field to a custom created field from the plug-in, let's say GPS1  the values will be different. Example:
From LR GPS : 41°0'27.19" N 28°57'56.359" E
The correct value entered was: 41°0'27.191" N 28°57'56.359" E,
but LR truncates to 41°0'27.19" N 28°57'56.359" E.
With this, we can prove that LR is not saving the value that you enter, but an approximation of that value. From what I read here LR is capable of correctly represent the precision of the typed GPS, but it does not show in the GPS field with that precision. It looks to be a display problem of the interface since the correct value entered seems to be in the database.
Things like that are very undesirable to be out in a product from Adobe. Normally we have a workflow and things like that are set at the moment that you are processing those images. After you will not remember what you did or what has to be corrected in cases like that. Adobe should take more care in testing before releasing a new version and prioritize old problems reported but not yet addressed.

Report

Report
LEGEND ,
Mar 12, 2019 Mar 12, 2019

Copied

"only the longitude was preserved but the latitude was incorrect and not matching the original or un-ExifTool version."

The displayed latitudes of the ExifTool version are within 3 x 10^-7 seconds of the original, roughly 1/1000 cm.  Does that make a difference to your application?

I'm guessing that this tiny difference might be caused by ExifTool converting the fractional form to decimal form and then back to fractional form when it copies the coordinates. If you upload one of the photos to Google, I can verify that's what's going on.

Report

Report
LEGEND ,
Mar 12, 2019 Mar 12, 2019

Copied

"I re-exported using the ExifTool and the altitude was preserved but only to  one decimal place"

That's curious. If you upload one of the photos, I can see what might be going on with ExifTool (and file a bug report with ExifTool if necessary).

Report

Report
LEGEND ,
Mar 12, 2019 Mar 12, 2019

Copied

...and also figure out why LR isn't exporting the original altitude (at any precision).

Report

Report
May 14, 2019 May 14, 2019

Copied

Lightroom Classic 8.3 was released today and contained a fix for this issue. Please update to 8.3 and verify that you are no longer seeing the issue. Thank you!

Report

Report
LEGEND ,
May 14, 2019 May 14, 2019

Copied

I tested LR 8.3, and both Save Metadata To File and Export now represent minutes in EXIF using a denominator of 10,000,000 (10^7), providing a precision of about 0.02 cm. Excellent!

(0.0185 cm = 111 km/degree-of-latitude / 60 minutes/degree * 1000 m/km * 100 cm/m * 10^-7)

Report

Report
Community Beginner ,
Jul 02, 2020 Jul 02, 2020

Copied

The same problems with Photoshop. Looks like PS is moving seconds part of coordinate to minutes part loosing precision from cm mode to approx 18.5 meters!

Report

Report
LEGEND ,
Jul 02, 2020 Jul 02, 2020

Copied

You posted this in a report of a Lightroom bug that has been fixed. Please start a new topic in the Photoshop category, and include: the steps needed to recreate the problem, screenshots of what you see, and the first 10 lines from the menu command Help > System Info.

Report

Report
LEGEND ,
Jul 05, 2020 Jul 05, 2020

Copied

LATEST
Tomasz posted a bug report in the Photoshop category, and Tomasz and another person have reported this bug:
https://feedback.photoshop.com/photoshop_family/topics/gps-location-changes-after-editing-in-camera-...