Skip to main content
K
KentSpain85
Known Participant
December 10, 2022
Answered

CR3 GPS coordinates are being read incorrectly, and ONLY in Lightroom

  • December 10, 2022
  • 1 reply
  • 957 views

Good afternoon everyone, 

I shoot mostly raw images (Canon R5), and to tag the images, I use two programs. GeoTag Photos Pro 2 for outings where I have my phone with me tagging the images. The other application I use is GeoPhoto Pro to tag the images manually (when I don't use the other application) and save them to the CR3. 

 

I'll show an example. Here is an image I manually tagged

This address and coordinates are correct. 

To verify this information, I used PIE (Photo Information Extractor) and it shows up correctly: 

So that's correct. Notice the West in the longitude. 

 

When I import the image into Lightroom I get these coordinates:

Throwing the image into East instead of West, and causing it to be in the middle of the Mediterrean Sea, haha. 

 

Well, I change the E to W and it's correct. 

Again, this seems to be an issue in Lightroom importing the address since other applications can see the correct GPS coordinates. 

 

Does anyone have any ideas on how to fix this? It's quite bothersome, especially since I'd have to manually change each image. 

Thank you,

Regards,

Kent

Madrid, Spain.

    This topic has been closed for replies.
    Correct answer johnrellis

    What I see when inspecting the file using Jeffrey Friedl's Metadata Viewer plug-in (which uses Phil Harvey's ExifTool) is in the attached screenshot:

     

     

    You will see that the GPS coordinates appear in two different places (presumably written that way by the GeoPhoto Pro app). The correct GPS data is in the EXIF section of the file's header, the incorrect GPS data appears in the XMP section of the file's header. Obviously LrC is reading the XMP data....which I would probably expect, but with raw images such as your CR3 files any additional XMP data is usually contained in XMP sidecar files. Maybe that's a bug in LrC, but as the acknowledged metadata expert @johnrellis will have a much better explanation as to why this is happening and if he thinks that LrC shouldn't be reading that XMP data from an original proprietary raw file. 


    Summary: The GeoPhoto Pro app has a bug, writing a different value into the XMP GPS fields than the corresponding EXIF fields.  LR also has a bug -- it should prefer EXIF over XMP when both are present.

     

    Gory Details

     

    To build on Jim's reply, here's another view of the GPS fields stored in the file (also produced by Exiftool):

    [EXIF] GPS Version ID    : 2.3.0.0
[EXIF] GPS Latitude Ref  : North
[EXIF] GPS Latitude      : 40 deg 28' 27.42"
[EXIF] GPS Longitude Ref : West
[EXIF] GPS Longitude     : 3 deg 51' 37.44"
[XMP]  GPS Latitude      : 40 deg 28' 27.42" N
[XMP]  GPS Longitude     : 3 deg 51' 37.44" E

    As Jim observed, the EXIF longitude is West while the XMP longitude is East.  That's clearly a bug in GeoPhoto Pro.  The easiest workaround is to run this command in the Command prompt after running GeoPhoto Pro and before importing into LR:

    exiftool -xmp:all= *.cr3

    (You'll have to download and install the free Exiftool.) That will delete the erroneous XMP fields.

     

    Jim asks about the presence of XMP in raw files. In general, LR does read XMP fields from raw files if no .xmp sidecar is present. This is by design: Some cameras store in-camera star ratings in XMP, and newer Nikon cameras have started writing default Develop settings into .nef files, which LR uses as camera-raw defaults.

     

    There are two reasons why other apps may be showing the EXIF fields rather than the XMP fields. First, many apps don't implement the XMP standard (I vaguely recall that Windows File Explorer does not). Second, the industry standards are ambiguous about whether to prefer XMP or EXIF when both are present.  The original XMP spec gave precedence to XMP, but the later Metadata Working Group standard gives precedence to EXIF (with some exceptions, which don't include GPS). 

     

    LR does a pretty good job of following MWG (Adobe was one of the instigators of MWG), but it looks like in this case it isn't correctly following MWG, giving precedence to XMP.  I'm not going to bother filing a bug report about this, because I'm certain, based on past experience, it will just go into the bit bucket. Even if the LR team did eventually decide to fix it, it would most likely be at least 6 months, probably longer, which won't be of any use to you in the meantime.

    1 reply

    johnrellis
    johnrellis
    Legend
    December 10, 2022

    Either the app recording the coordinates isn't strictly obeying the industry standard or LR isn't (both have happened in the past). To determine the culprit, upload a sample .cr3 to Dropbox, Google Drive, or similar and post the sharing link here. We'll stick it under the microscope, and if it's a LR bug, file a bug report.

    K
    KentSpain85Author
    Known Participant
    December 11, 2022

    Thank you. Here is the RAW file I tagged with those coordinates. Link to Google Drive. Even inspecting it in Windows' file properties, the coordinates are correct. 

    This is why it's so curious. 

     

    Anyways, thank you very much! I appreciate your help and input on the matter. 

    johnrellis
    johnrellisCorrect answer
    Legend
    December 11, 2022

    What I see when inspecting the file using Jeffrey Friedl's Metadata Viewer plug-in (which uses Phil Harvey's ExifTool) is in the attached screenshot:

     

     

    You will see that the GPS coordinates appear in two different places (presumably written that way by the GeoPhoto Pro app). The correct GPS data is in the EXIF section of the file's header, the incorrect GPS data appears in the XMP section of the file's header. Obviously LrC is reading the XMP data....which I would probably expect, but with raw images such as your CR3 files any additional XMP data is usually contained in XMP sidecar files. Maybe that's a bug in LrC, but as the acknowledged metadata expert @johnrellis will have a much better explanation as to why this is happening and if he thinks that LrC shouldn't be reading that XMP data from an original proprietary raw file. 


    Summary: The GeoPhoto Pro app has a bug, writing a different value into the XMP GPS fields than the corresponding EXIF fields.  LR also has a bug -- it should prefer EXIF over XMP when both are present.

     

    Gory Details

     

    To build on Jim's reply, here's another view of the GPS fields stored in the file (also produced by Exiftool):

    [EXIF] GPS Version ID    : 2.3.0.0
[EXIF] GPS Latitude Ref  : North
[EXIF] GPS Latitude      : 40 deg 28' 27.42"
[EXIF] GPS Longitude Ref : West
[EXIF] GPS Longitude     : 3 deg 51' 37.44"
[XMP]  GPS Latitude      : 40 deg 28' 27.42" N
[XMP]  GPS Longitude     : 3 deg 51' 37.44" E

    As Jim observed, the EXIF longitude is West while the XMP longitude is East.  That's clearly a bug in GeoPhoto Pro.  The easiest workaround is to run this command in the Command prompt after running GeoPhoto Pro and before importing into LR:

    exiftool -xmp:all= *.cr3

    (You'll have to download and install the free Exiftool.) That will delete the erroneous XMP fields.

     

    Jim asks about the presence of XMP in raw files. In general, LR does read XMP fields from raw files if no .xmp sidecar is present. This is by design: Some cameras store in-camera star ratings in XMP, and newer Nikon cameras have started writing default Develop settings into .nef files, which LR uses as camera-raw defaults.

     

    There are two reasons why other apps may be showing the EXIF fields rather than the XMP fields. First, many apps don't implement the XMP standard (I vaguely recall that Windows File Explorer does not). Second, the industry standards are ambiguous about whether to prefer XMP or EXIF when both are present.  The original XMP spec gave precedence to XMP, but the later Metadata Working Group standard gives precedence to EXIF (with some exceptions, which don't include GPS). 

     

    LR does a pretty good job of following MWG (Adobe was one of the instigators of MWG), but it looks like in this case it isn't correctly following MWG, giving precedence to XMP.  I'm not going to bother filing a bug report about this, because I'm certain, based on past experience, it will just go into the bit bucket. Even if the LR team did eventually decide to fix it, it would most likely be at least 6 months, probably longer, which won't be of any use to you in the meantime.

      Terms & ConditionsAccessibility statement
      Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices