Champion

•

5.6K Messages

•

98.1K Points

Wed, Feb 20, 2019 8:40 PM

Solved

# Lightroom Classic: Loses precision in exported EXIF GPS coordinates

[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.

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:

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

Problems

•

Updated

8 months ago

34

9

#### Helpful Widget

How can we improve?

#### Tags

No tags available

## Responses

## G0apher

Employee

•

112 Messages

•

2.1K Points

2 years ago

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

1

## parker_hill_akb9vg7mfakc2

5 Messages

•

108 Points

2 years ago

I would be grateful for any help.

1

0

## John_R_Ellis

Champion

•

5.6K Messages

•

98.1K Points

2 years ago

The "Command per image" is:

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.

0

0

## parker_hill_akb9vg7mfakc2

5 Messages

•

108 Points

2 years ago

Thanks in advance.

2

0

## John_R_Ellis

Champion

•

5.6K Messages

•

98.1K Points

2 years ago

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:

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.

6

## thales_martins_7101741

4 Messages

•

208 Points

2 years ago

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.

0

0

## Rikk

Adobe Administrator

•

9.4K Messages

•

130.5K Points

2 years ago

Quality Engineering - Customer Advocacy

0

## John_R_Ellis

Champion

•

5.6K Messages

•

98.1K Points

2 years ago

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

0

## tomasz_szabon

3 Messages

•

92 Points

8 months ago

2

0